3 ms·

Not a whole list of operations, but this comparison of one common operation between jj and git is what made it click for me. https://lottia.net/notes/0013-git-

by dcre 1y ago

Not a whole list of operations, but this comparison of one common operation between jj and git is what made it click for me. https://lottia.net/notes/0013-git-jujutsu-miniature.html https://lottia.net/notes/0013-git-jujutsu-miniature.html

doritosfan84 1y ago
Thanks. This is a really good one. It outlines an operation that would resonate well with most developers and clearly demonstrates how much simpler, easier, and faster this is in jujutsu vs git. I think most devs just wouldn't even bother to do it in git, they'd leave the test out of order and call it a day.
- dcre 1y ago
  Yep, I think that's right. As the other reply says, this is part of what makes it hard to explain. If you told me jj makes it easy to rebase all the time, I would ask: why do I want to do that? Now I don't even think about it, I just rebase all the time.
wredcoll 1y ago
This article convinces me that what he wants to do is easier in jj, I just don't understand why he wants to do it. My quick summary is that in one case he's try to avoid "extra" commits and in another case he's trying to re-order some commits. In my usual work flow, both of those problems would be handled by the git-rebase-squash I do after the feature works.
- dcre 1y ago
  See the other replies: the point is that jj makes these operations so trivial that if you have the slightest whim to do them, you can just do them.
idoubtit 1y ago
I think that comparison is unclear and unfair. The core is that instead of: jj rebase -r @ -B abc the recommended Git alternative is: git rebase -i abcd1234 # move the last line to the desired position This is a process I use heavily, and one of the rare cases where I prefer the Git way: less cognitive load (I don't need to memorise options b/s/r/d/A/B for `jj rebase`) and the interactive editing of the history feels simpler (especially if I move several commits). I've used jj for a few weeks, but switched back to git. I'm fluent enough with Git so I never struggle any more. jj mostly felt nice, but the added value was not enough to replace years of expertise.
- baq 1y ago
  I find jj rebase -b @ -d master@origin to be an excellent improvement over anything git provides, including rerere. It's the first patch queue for git implementation that actually worked for me, which in turn makes github PR UI somewhat bearable. I occasionally use -r, too, but most of the time it's better to jj squash --from ... --into @

by dcre 1y ago

doritosfan84 1y ago

Thanks. This is a really good one. It outlines an operation that would resonate well with most developers and clearly demonstrates how much simpler, easier, and faster this is in jujutsu vs git. I think most devs just wouldn't even bother to do it in git, they'd leave the test out of order and call it a day.

dcre 1y ago
Yep, I think that's right. As the other reply says, this is part of what makes it hard to explain. If you told me jj makes it easy to rebase all the time, I would ask: why do I want to do that? Now I don't even think about it, I just rebase all the time.

wredcoll 1y ago

This article convinces me that what he wants to do is easier in jj, I just don't understand why he wants to do it. My quick summary is that in one case he's try to avoid "extra" commits and in another case he's trying to re-order some commits. In my usual work flow, both of those problems would be handled by the git-rebase-squash I do after the feature works.

dcre 1y ago
See the other replies: the point is that jj makes these operations so trivial that if you have the slightest whim to do them, you can just do them.

idoubtit 1y ago

I think that comparison is unclear and unfair. The core is that instead of: jj rebase -r @ -B abc the recommended Git alternative is: git rebase -i abcd1234 # move the last line to the desired position This is a process I use heavily, and one of the rare cases where I prefer the Git way: less cognitive load (I don't need to memorise options b/s/r/d/A/B for `jj rebase`) and the interactive editing of the history feels simpler (especially if I move several commits). I've used jj for a few weeks, but switched back to git. I'm fluent enough with Git so I never struggle any more. jj mostly felt nice, but the added value was not enough to replace years of expertise.

baq 1y ago
I find jj rebase -b @ -d master@origin to be an excellent improvement over anything git provides, including rerere. It's the first patch queue for git implementation that actually worked for me, which in turn makes github PR UI somewhat bearable. I occasionally use -r, too, but most of the time it's better to jj squash --from ... --into @