3 ms·

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

> 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."
  - frizlab 1y ago
    > it's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done” Neither. Rebasing is an atomic task, kinda like a commit.
    - BeetleB 1y ago
      > Rebasing is an atomic task I may be misinterpreting your position, but I suspect you consider rebasing and fixing conflicts together as the atomic task. In jujutsu, these are two separate tasks. You do a rebase. Even if there are conflicts, the rebase is done. Fixing conflicts is its own task, and can be done at your leisure - no need to couple the two. It's like writing some code that broke a test. You don't say "Hey, I'd rather not work on anything else until this is fixed." If you want, you either commit it as is (or stash if you prefer), work on something else, and come back to it later to fix the broken test.
      - frizlab 1y ago
        > You don't say "Hey, I'd rather not work on anything else until this is fixed." Hey that’s where we differ I guess! I do (most of the time, and if I truly need to switch, my workspace is cloned usually at least twice, using worktrees, so I can indeed switch whatever the current status of everything). This is broadly what I was saying above, most of the “problems” git have are solved with worktrees, that have the undeniable advantage (IMHO) to actually separate tasks, instead of being in a state where (waving hands) everything is here in this big bowl of stuff (and I’m not saying that dismissively; once again everybody works differently; it’s just not my thing). I do have understood the “conflicts do not need to be resolved straight away,” though I do not really get it (if there are conflicts the code does not compile anymore, so what is even the point? ok you can switch branch, but still it’s a task that I would know I have to do anyway and I could not switch to something else; my brain does not work that way). All of that being said, since you seem to know a lot about jj, I’ll take the liberty to ask a question I do have about it, because there is indeed a workflow that I find painful with git that, IIUC, is actually solved by jj. Let’s say I (or the team) am (is) working on two or three different things on two or three different branches. The full feature is the merge of these branches. Is jj able to maintain a branch which is the merge of all the other branches mostly (or fully) automatically?

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."
- frizlab 1y ago
  > it's like saying "Humans are bad at multitasking - they should never switch to another branch until the current feature is done” Neither. Rebasing is an atomic task, kinda like a commit.
  - BeetleB 1y ago
    > Rebasing is an atomic task I may be misinterpreting your position, but I suspect you consider rebasing and fixing conflicts together as the atomic task. In jujutsu, these are two separate tasks. You do a rebase. Even if there are conflicts, the rebase is done. Fixing conflicts is its own task, and can be done at your leisure - no need to couple the two. It's like writing some code that broke a test. You don't say "Hey, I'd rather not work on anything else until this is fixed." If you want, you either commit it as is (or stash if you prefer), work on something else, and come back to it later to fix the broken test.
    - frizlab 1y ago
      > You don't say "Hey, I'd rather not work on anything else until this is fixed." Hey that’s where we differ I guess! I do (most of the time, and if I truly need to switch, my workspace is cloned usually at least twice, using worktrees, so I can indeed switch whatever the current status of everything). This is broadly what I was saying above, most of the “problems” git have are solved with worktrees, that have the undeniable advantage (IMHO) to actually separate tasks, instead of being in a state where (waving hands) everything is here in this big bowl of stuff (and I’m not saying that dismissively; once again everybody works differently; it’s just not my thing). I do have understood the “conflicts do not need to be resolved straight away,” though I do not really get it (if there are conflicts the code does not compile anymore, so what is even the point? ok you can switch branch, but still it’s a task that I would know I have to do anyway and I could not switch to something else; my brain does not work that way). All of that being said, since you seem to know a lot about jj, I’ll take the liberty to ask a question I do have about it, because there is indeed a workflow that I find painful with git that, IIUC, is actually solved by jj. Let’s say I (or the team) am (is) working on two or three different things on two or three different branches. The full feature is the merge of these branches. Is jj able to maintain a branch which is the merge of all the other branches mostly (or fully) automatically?