I've seen several posts on jj, but could anyone please tell what can't be done by git, or what is harder in git but super-easy in jj by providing the sequence of git commands and jj commands for comparison?
You can do everything in Git really. I don't see anything in jj that Git literally can't do, but as someone who spends a lot of time faffing around rebasing huge branches I can really see the appeal of something that does all the same stuff better.
If I mostly worked on a small-to-medium size project with close connections between developers, where mostly you just get your code merged pretty quickly or drop it, then I wouldn't see any value in it. But for Linux kernel work git can often be pretty tiresome, even if it never actually gets in the way.
I thought that nothing could beat Git until I tried Fig (Google's Mercurial thing). It ends up being awful coz it's so bloody slow, but it convinced me that a more advanced model of the history can potentially life easier more often than it makes it harder.
Fig's model differs from Git in totally different ways than jj's does but just abstractly it showed me that VCS could be meaningfully improved.
Yes, at the end of the day, there's nothing you can't do in git that you can do in jj. This is easy to demonstrate, since jj has a git backend. There are minor things about that that do show some things, like for example, change IDs are totally local, and not shared, since git doesn't have the notion of a change ID, but that's not what we're talking about really.
At the end of the day, every DVCS is ultimately "here is a repository that is a bunch of snapshots of your working directory and a graph of those snapshots" plus tools to work with the graph, including tools to speak to other repositories.
From any given snapshot A -> B, both git and jj can get you there. The question is, which tools are more effective for getting the work done that you want to do?
git commit --fixup X ; git rebase --interactive --autostash --autosquash X^
If you do that often, an alias might help; I have one for the second command above. You might want to look at git-fixup or git-absorb for automatically finding the "X" commit.
Aside: I really ought to try jj, it looks very promising.
That looks more like a git alias than a job for an entirely new tool, to me. How many of the core functions do you really need to cover before `jj` itself becomes redundant?
bjackman|1 year ago
If I mostly worked on a small-to-medium size project with close connections between developers, where mostly you just get your code merged pretty quickly or drop it, then I wouldn't see any value in it. But for Linux kernel work git can often be pretty tiresome, even if it never actually gets in the way.
I thought that nothing could beat Git until I tried Fig (Google's Mercurial thing). It ends up being awful coz it's so bloody slow, but it convinced me that a more advanced model of the history can potentially life easier more often than it makes it harder.
Fig's model differs from Git in totally different ways than jj's does but just abstractly it showed me that VCS could be meaningfully improved.
steveklabnik|1 year ago
At the end of the day, every DVCS is ultimately "here is a repository that is a bunch of snapshots of your working directory and a graph of those snapshots" plus tools to work with the graph, including tools to speak to other repositories.
From any given snapshot A -> B, both git and jj can get you there. The question is, which tools are more effective for getting the work done that you want to do?
martinvonz|1 year ago
`git commit --fixup=X foo; git stash; git rebase -i X^; git stash pop`
`jj squash --into X foo`
Aissen|1 year ago
git commit --fixup X ; git rebase --interactive --autostash --autosquash X^
If you do that often, an alias might help; I have one for the second command above. You might want to look at git-fixup or git-absorb for automatically finding the "X" commit.
Aside: I really ought to try jj, it looks very promising.
Martinussen|1 year ago