6 ms·

>you have to manually rebase every subsequent change What do you mean by this? You can do an interactive rebase in git as well. The real issue is non-trivial m

>you have to manually rebase every subsequent change What do you mean by this? You can do an interactive rebase in git as well. The real issue is non-trivial merge conflicts which is going to be an issue no matter you use.

sunshowers 1y ago
git rebase -i is a much worse experience than jj's autorebasing of descendants. For example, with git rebase -i you can't decide to do something else in the middle of the rebase — you're in that state until the rebase is completed or abandoned. Merge conflicts are also significantly better with jj because they don't interrupt the rest of your flow. And most importantly, the two features work together to create something greater than the sum of its parts. See my testimonial (first one) at https://jj-vcs.github.io/jj/latest/testimonials/#what-the-users-have-to-say https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us...
- packetlost 1y ago
  > with git rebase -i you can't decide to do something else in the middle of the rebase You absolutely can, to some degree. At any point in an interactive rebase you can just make your changes and do a normal `git commit` then do `git rebase --continue` along on your merry way. Unless you're talking about suspending the rebase and like switching branches, messing around, and then resuming the rebase, which is kind of a weird thing to do.
  - sunshowers 1y ago
    I do mean suspending the rebase and going to do something else, yes. It's a weird thing to do in git, because the conditions that git creates makes it weird. It is completely natural with jj, because jj doesn't have any modal states at all. (This is one of the key reasons jj is both simpler and more powerful than git — no modal states.)
    - frizlab 1y ago
      Modal states are actually good IMHO.
      - sunshowers 1y ago
        I feel like I just outlined a situation where something that's weird in git is completely natural in jj. Maybe I miscommunicated?
        frizlab 1y ago
        I think you communicated well, probably I did not. > suspending the rebase and going to do something else This is what I find to be weird, personally. When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me. At first approach (I read a (very good) intro[1]; I did not try), it seems there’s a lot of new things to learn (for instance the revsets language), for a very minimal gain, so I’m (still) gonna pass on it. It feels like jj is solving a lot of problems that do not exist, or are mostly solved with worktrees. That being said it’s true that everybody’s way of working is different, so I don’t know! Maybe jj will be picked up by the younger generation and it will become the new de facto standard. Time will tell… Personally, the current VCS tool I’d like to try now instead of jj is fossil. It seems much more interesting as it promises to allow bypassing GitHub/other forge completely by being the full forge itself. In these days, having ownership of one’s data feels primordial to me. [1] https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
        KingMob 1y ago
        I think the evergreen use case for interrupting a rebase is, your manager came over to ask if you can drop everything and look at this bug that $TOP_CLIENT is screaming about. Git worktrees suffice, but they're still heavier weight than `jj new whatever`.
        packetlost 1y ago
stouset 1y ago
Let's say I have five commits in a row ready to go, but they should be reviewed and merged one-by-one. Upon review, I need to make a change to the first commit. How much work do you think this would be in git? How much of a pain in the ass do you think it would be if a later change conflicted with this earlier change? It is essentially zero work in jj. I `jj edit` the revision in question, make the change, and `jj push`.
- packetlost 1y ago
  It's really not a lot at all. The weakness is in "forge" tools like GitHub that add a PR/changelist abstraction on top of git and don't support sequences of patches. If you're using just commits and maybe (mailed) patches you only do a single `git rebase` (with -i if you want) and you're done. Unless jj is literally magic and can automatically fix conflicts, I can't see how it would actually reduce the work involved in a meaningful way.
  - plandis 1y ago
    As far as I know, by default Git doesn’t enable the “reuse recorded resolution” feature so if you made a change to the first commit you’d have to manually do the same thing for any subsequent commits.
    - packetlost 1y ago
      If you have 5 different branches, sure. Again, the reason you create a bunch of branches for separate review is because that's what the "git forge" abstraction generally expects. It's not actually how code reviews are done by the people who wrote it. You can also just enable that feature (rerere).
      - wredcoll 1y ago
        What is the "right" way to do it then? Also probably most of us are stuck with whatever git*.com supports anyways...

sunshowers 1y ago

git rebase -i is a much worse experience than jj's autorebasing of descendants. For example, with git rebase -i you can't decide to do something else in the middle of the rebase — you're in that state until the rebase is completed or abandoned. Merge conflicts are also significantly better with jj because they don't interrupt the rest of your flow. And most importantly, the two features work together to create something greater than the sum of its parts. See my testimonial (first one) at https://jj-vcs.github.io/jj/latest/testimonials/#what-the-users-have-to-say https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us...

packetlost 1y ago
> with git rebase -i you can't decide to do something else in the middle of the rebase You absolutely can, to some degree. At any point in an interactive rebase you can just make your changes and do a normal `git commit` then do `git rebase --continue` along on your merry way. Unless you're talking about suspending the rebase and like switching branches, messing around, and then resuming the rebase, which is kind of a weird thing to do.
- sunshowers 1y ago
  I do mean suspending the rebase and going to do something else, yes. It's a weird thing to do in git, because the conditions that git creates makes it weird. It is completely natural with jj, because jj doesn't have any modal states at all. (This is one of the key reasons jj is both simpler and more powerful than git — no modal states.)
  - frizlab 1y ago
    Modal states are actually good IMHO.
    - sunshowers 1y ago
      I feel like I just outlined a situation where something that's weird in git is completely natural in jj. Maybe I miscommunicated?
      - frizlab 1y ago
        I think you communicated well, probably I did not. > suspending the rebase and going to do something else This is what I find to be weird, personally. When doing a rebase, there’s no way I want to do something else in the middle of it, and having a modal state feels totally natural to me. At first approach (I read a (very good) intro[1]; I did not try), it seems there’s a lot of new things to learn (for instance the revsets language), for a very minimal gain, so I’m (still) gonna pass on it. It feels like jj is solving a lot of problems that do not exist, or are mostly solved with worktrees. That being said it’s true that everybody’s way of working is different, so I don’t know! Maybe jj will be picked up by the younger generation and it will become the new de facto standard. Time will tell… Personally, the current VCS tool I’d like to try now instead of jj is fossil. It seems much more interesting as it promises to allow bypassing GitHub/other forge completely by being the full forge itself. In these days, having ownership of one’s data feels primordial to me. [1] https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
        KingMob 1y ago
        I think the evergreen use case for interrupting a rebase is, your manager came over to ask if you can drop everything and look at this bug that $TOP_CLIENT is screaming about. Git worktrees suffice, but they're still heavier weight than `jj new whatever`.
        packetlost 1y ago

stouset 1y ago

Let's say I have five commits in a row ready to go, but they should be reviewed and merged one-by-one. Upon review, I need to make a change to the first commit. How much work do you think this would be in git? How much of a pain in the ass do you think it would be if a later change conflicted with this earlier change? It is essentially zero work in jj. I `jj edit` the revision in question, make the change, and `jj push`.

packetlost 1y ago
It's really not a lot at all. The weakness is in "forge" tools like GitHub that add a PR/changelist abstraction on top of git and don't support sequences of patches. If you're using just commits and maybe (mailed) patches you only do a single `git rebase` (with -i if you want) and you're done. Unless jj is literally magic and can automatically fix conflicts, I can't see how it would actually reduce the work involved in a meaningful way.
- plandis 1y ago
  As far as I know, by default Git doesn’t enable the “reuse recorded resolution” feature so if you made a change to the first commit you’d have to manually do the same thing for any subsequent commits.
  - packetlost 1y ago
    If you have 5 different branches, sure. Again, the reason you create a bunch of branches for separate review is because that's what the "git forge" abstraction generally expects. It's not actually how code reviews are done by the people who wrote it. You can also just enable that feature (rerere).
    - wredcoll 1y ago
      What is the "right" way to do it then? Also probably most of us are stuck with whatever git*.com supports anyways...