4 ms·

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 do

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!
      - sunshowers 1y ago
        Been a long time since I used git, but --edit-todo only changes what's still to come, right? It doesn't let you go back and edit earlier commits in the stack.
        packetlost 1y ago
        Ah, yeah it does only allow you to modify the remaining todos :/
stouset 1y ago
> 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. This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution. Rebase conflicts are (to a jj user) just another fix you might want to make to a revision. Or it might be better done by making a tweak to an earlier revision, instead of the revision where the conflict first occurred. There’s no pressure to fix it right this second, you can always come back where you left off. And you can make your fixed in a separate commit that you squash into the conflicted commit if it’s particularly hairy. > It feels like jj is solving a lot of problems that do not exist, or are mostly solved with worktrees. Git has grown a lot of features over the years and countless flags to make some things feasible. jj rethinks the core interaction model in a way that gets rid of all the band-aids. There are people who still live and die by C and swear that anyone running into issues is holding it wrong or just needs to be more principled about how they handle memory. But most people have moved on to higher-level languages. It doesn’t mean C was a bad language, it doesn’t mean those programmers weren’t familiar with C, and it doesn’t mean there aren’t still some cases where C is the right answer. But most people nowadays find other languages more productive with less friction.
- frizlab 1y ago
  > This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution. Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing… Relaxing this comment which is a bit aggressive: at least it’s how I work. YMMV.
  - BeetleB 1y ago
    > Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing… Again, see my other comment. It's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done."
BeetleB 1y ago
> 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. When I was pure git, I agreed. Let me reframe your comment: "When working on a feature, there's no way I want to work on some other feature in the middle of it" (which is how many people felt before ever using version control and branches). With jj, I do it all the time. The tool made the difference. A rebase is not something "special". Switching from a rebase to working on another feature in the middle is exactly just like switching to another branch in the middle of working on the current branch. It's the same (or very similar) set of commands. When you realize this, then yeah - leaving in the middle of a rebase is pretty normal, and you wonder why people don't do it.

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!
    - sunshowers 1y ago
      Been a long time since I used git, but --edit-todo only changes what's still to come, right? It doesn't let you go back and edit earlier commits in the stack.
      - packetlost 1y ago
        Ah, yeah it does only allow you to modify the remaining todos :/

stouset 1y ago

> 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. This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution. Rebase conflicts are (to a jj user) just another fix you might want to make to a revision. Or it might be better done by making a tweak to an earlier revision, instead of the revision where the conflict first occurred. There’s no pressure to fix it right this second, you can always come back where you left off. And you can make your fixed in a separate commit that you squash into the conflicted commit if it’s particularly hairy. > It feels like jj is solving a lot of problems that do not exist, or are mostly solved with worktrees. Git has grown a lot of features over the years and countless flags to make some things feasible. jj rethinks the core interaction model in a way that gets rid of all the band-aids. There are people who still live and die by C and swear that anyone running into issues is holding it wrong or just needs to be more principled about how they handle memory. But most people have moved on to higher-level languages. It doesn’t mean C was a bad language, it doesn’t mean those programmers weren’t familiar with C, and it doesn’t mean there aren’t still some cases where C is the right answer. But most people nowadays find other languages more productive with less friction.

frizlab 1y ago
> This is a consequence of rebases being a special, modal state that requires dedicated focus to work through to resolution. Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing… Relaxing this comment which is a bit aggressive: at least it’s how I work. YMMV.
- BeetleB 1y ago
  > Believe it or not: no. Humans are notoriously bad at multitasking, so it makes sense to actually finish a task before moving to something else and forgetting what we were doing… Again, see my other comment. It's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done."

BeetleB 1y ago

> 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. When I was pure git, I agreed. Let me reframe your comment: "When working on a feature, there's no way I want to work on some other feature in the middle of it" (which is how many people felt before ever using version control and branches). With jj, I do it all the time. The tool made the difference. A rebase is not something "special". Switching from a rebase to working on another feature in the middle is exactly just like switching to another branch in the middle of working on the current branch. It's the same (or very similar) set of commands. When you realize this, then yeah - leaving in the middle of a rebase is pretty normal, and you wonder why people don't do it.