4 ms·

> 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 rebas

> 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
        I've had maybe 3-4 occasions in my entire career where I was working with a rebase large enough where it took multiple sittings (every single one sucked badly). I'm not going to argue that it's not something that comes up, but I will say that if it's common, your workflow is probably too chaotic for me. That being said, you can still do that in git (see sibling comment to this one), but it is more involved. IMO that's good because I don't think enabling that type of chaotic, jumpy workflow is healthy or good.
        sunshowers 1y ago
        Well for me it's happened hundreds of times. Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack. > IMO that's good because I don't think enabling that type of chaotic, jumpy workflow is healthy or good. Nah, it's wonderful. You see it as chaotic and jumpy because the conditions Git creates makes it feel chaotic and jumpy. It's like being terrified of multithreaded code if you're not using Rust or a purely functional language.
        packetlost 1y ago
        > Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack I think this is what `git rebase --edit-todo` is for. >Nah, it's wonderful. You see it as chaotic and jumpy because the conditions Git creates makes it feel chaotic and jumpy. Fair enough. `jj` probably isn't right for me, but I'm happy it works well for you!
  - tcoff91 1y ago
    First class conflicts are way better than modal states. https://ofcr.se/jujutsu-merge-workflow/ https://ofcr.se/jujutsu-merge-workflow/ I literally will have like 4 PRs in flight at once and have an octopus merge of all my separate PRs that I can then work on top of. JJ can rebase all 4 separate branches, the octopus merge, and the work on top of the octopus merge in a single command: jj rebase -d main. If there are conflicts I can then resolve them whenever I want. You have no idea what you are talking about if you think git’s interactive rebase holds a candle to what jj rebase can do.
- 1718627440 1y ago
  You can absolutely do that in git: git checkout master git rebase [whatever] [rebasing stuff] git tag rebasing git checkout --detach master [do random other stuff] git tag todo git checkout rebasing [continue rebasing] When you are not trying to modify the same branch you're rebasing, you can omit --detach and also git tag todo. (To clarify, it has never occurred to me that I even want to do that, so I didn't knew how to do it. Yet I didn't even needed to consider a manual, it just follows naturally from the git user model even if it seams completely unidiomatic.)
  - sunshowers 1y ago
    As far as I know you can't start another rebase -i while you're in this situation. But it's been almost two years since I last used rebase -i so I might be wrong.
    - 1718627440 1y ago
      Yes, that's because a rebase in git is nothing special, so you influence the rebase with normal git commands. When you do normal interaction like committing or resetting these become part of the rebase.
  - BeetleB 1y ago
    I know you're trying to point out how easy it is in git, and some months ago I would have agreed. But after using jj (for only a few weeks!), your commands seem needlessly complex. In jj, you run the rebase command. If you get conflicts, and want to switch to something else before you fix all of them, you simply do "jj edit" or "jj new" and work on something else. Then you do "jj edit" to go back to the conflicted revision and get back to fixing conflicts. The key point is: You don't need to learn any new concepts. In the git example above, I need to know tagging. I need to know checkout vs "checkout --detach", etc. I'm not saying your git commands are crazy complex. They're merely more complex than one needs to solve this particular problem.
    - 1718627440 1y ago

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
        I've had maybe 3-4 occasions in my entire career where I was working with a rebase large enough where it took multiple sittings (every single one sucked badly). I'm not going to argue that it's not something that comes up, but I will say that if it's common, your workflow is probably too chaotic for me. That being said, you can still do that in git (see sibling comment to this one), but it is more involved. IMO that's good because I don't think enabling that type of chaotic, jumpy workflow is healthy or good.
        sunshowers 1y ago
        Well for me it's happened hundreds of times. Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack. > IMO that's good because I don't think enabling that type of chaotic, jumpy workflow is healthy or good. Nah, it's wonderful. You see it as chaotic and jumpy because the conditions Git creates makes it feel chaotic and jumpy. It's like being terrified of multithreaded code if you're not using Rust or a purely functional language.
        packetlost 1y ago
        > Specifically I've very often wanted to do another git rebase -i in the middle of the first one, usually because I changed my mind about something and want to make changes to an earlier commit in my stack I think this is what `git rebase --edit-todo` is for. >Nah, it's wonderful. You see it as chaotic and jumpy because the conditions Git creates makes it feel chaotic and jumpy. Fair enough. `jj` probably isn't right for me, but I'm happy it works well for you!
- tcoff91 1y ago
  First class conflicts are way better than modal states. https://ofcr.se/jujutsu-merge-workflow/ https://ofcr.se/jujutsu-merge-workflow/ I literally will have like 4 PRs in flight at once and have an octopus merge of all my separate PRs that I can then work on top of. JJ can rebase all 4 separate branches, the octopus merge, and the work on top of the octopus merge in a single command: jj rebase -d main. If there are conflicts I can then resolve them whenever I want. You have no idea what you are talking about if you think git’s interactive rebase holds a candle to what jj rebase can do.
1718627440 1y ago
You can absolutely do that in git: git checkout master git rebase [whatever] [rebasing stuff] git tag rebasing git checkout --detach master [do random other stuff] git tag todo git checkout rebasing [continue rebasing] When you are not trying to modify the same branch you're rebasing, you can omit --detach and also git tag todo. (To clarify, it has never occurred to me that I even want to do that, so I didn't knew how to do it. Yet I didn't even needed to consider a manual, it just follows naturally from the git user model even if it seams completely unidiomatic.)
- sunshowers 1y ago
  As far as I know you can't start another rebase -i while you're in this situation. But it's been almost two years since I last used rebase -i so I might be wrong.
  - 1718627440 1y ago
    Yes, that's because a rebase in git is nothing special, so you influence the rebase with normal git commands. When you do normal interaction like committing or resetting these become part of the rebase.
- BeetleB 1y ago
  I know you're trying to point out how easy it is in git, and some months ago I would have agreed. But after using jj (for only a few weeks!), your commands seem needlessly complex. In jj, you run the rebase command. If you get conflicts, and want to switch to something else before you fix all of them, you simply do "jj edit" or "jj new" and work on something else. Then you do "jj edit" to go back to the conflicted revision and get back to fixing conflicts. The key point is: You don't need to learn any new concepts. In the git example above, I need to know tagging. I need to know checkout vs "checkout --detach", etc. I'm not saying your git commands are crazy complex. They're merely more complex than one needs to solve this particular problem.
  - 1718627440 1y ago