[1718627440]

> I was thinking that you would have to use interactive rebase instead because you can no longer make those changes in the working copy and use `git commit --fixup`, right? And because there will now be conflicts in commit B, you will be in this "interrupted rebase" state

Yes.

I don't see the drawback honestly. Invoking git rebase, means I want to resolve conflicts now, when I want to do that later, I can just call git rebase later. When you want to work on top of the B with conflicts, the code wouldn't even compile, so I expect JJ, to just give you the code before the squash, right? How is this different from in Git?

[martinvonz]

The difference is that jj doesn't force you to resolve the conflict right away. I agree that you usually want to do that anyway, but it has happened to me many times that some conflict turned out to be more complicated than I had time for at the moment and I needed to work on something else for a while. When using Git, I would typically abort the rebase in such cases, which is not so bad if you have rerere enabled (I can't remember if it records any resolutions I had staged or if that's only one you commit).

Anyway, I'm just explaining how jj works and what I prefer. As Steve always says, you should use the tools you prefer :)

[1718627440]

> When using Git, I would typically abort the rebase in such cases, which is not so bad if you have rerere enabled

Yes, I do the same. I think it's not too different. You can also commit randomly somewhere else, it is only a problem once you try to start another rebase or merge. (But I never needed to do it, I just tried it out during discussions like this.)

> Anyway, I'm just explaining how jj works and what I prefer. As Steve always says, you should use the tools you prefer :)

Sure. I'm not objecting to you using JJ, I was objecting to you stating, that it is "much harder" in Git. This is seems to be a common sentiment among JJ users, but it always seem to amount to that people bother to read the manual and understand the tool AFTER they used a VCS for years.

[martinvonz]

> it always seem to amount to that people bother to read the manual and understand the tool AFTER they used a VCS for years.

Perhaps, but I don't think that's true for me (or for Steve). I've contributed something like 90 patches to Git itself (mostly to the rebase code). To be fair, that was a while ago.

My impression is actually that many people who disagree with the sentiment that jj is much easier to use seem to have not read its manual :) Some of them seem to have not even tried it. So, the way it looks to me, it's usually the people who argue for jj who have a better understanding of the differences between the two tools.

Have you tried jj yourself and/or have you read some of the documentation?

[1718627440]

I wanted, but it didn't compile due to needing a newer Rust compiler, than is available in my Distro. And the tutorials I found told me to run the equivalent of curl|bash, which I will not do. I don't felt like learning a new language/ecosystem just to try out another VCS, so I said, it's not worth it, I wait until it is available in my distro.

So actually no, and you have a point. :-)

I often just read "this is hard in Git" and think isn't this just this command? JJ has some nice features, but what appeals to me seems to not to be that hard to add to Git, so I will just wait a bit.