[stouset]

> I personally never use rebase

Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do.

Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.

Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch B needs to be merged before Branch C. It’s a massive pain with git, especially if you need to change Branch A. It’s a no-op in jj.

There are a ton of straightforward and useful workflows in git that are just completely impractical.

[bayindirh]

No, not because it's painful, I just don't need it.

> Do you ever want to go back and edit a previous unpublished commit?

Honestly, no? I plan what I'm going to change, do it, commit it, and if I messed up, I don't hide it, just fix it and write "I messed up X in $HASH. This fixes that".

> Do you ever want to maintain a linear chain of branches?

No, I always keep a single thing moving at one time. If the project is big, I use a branch per feature, if it's a smaller branch, there's a development branch. That's all. I have a habit of designing before touching code, so I always move in well planned moves.

It's not like that because I'm afraid of rebase. It's just how I design/implement software. Yes, it's generally not a group work, but I do what I do, and it works.

> There are a ton of straightforward and useful workflows in git that are just completely impractical.

That's fine. I don't claim otherwise. I just don't do to prefer source code / branch acrobatics. I'd love to share a seven year development tree to show how I work, but unfortunately that repo is not meant to be open, at least for now.

[Izkata]

> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.

Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.

[Valodim]

This is roughly the reaction I meant going into this discussion :)

The rebase next level part is not about using git rebase in the right way, it's about every command including status sometimes doing 15 rebases without even mentioning it.

[steveklabnik]

What jj does is not require you to pause. It’s fine with leaving stuff in a conflicted state, letting you do whatever you want as a next step. That may be resolving the rebase, but maybe you didn’t realize you were gonna have a conflict and want to get something else done real quickly.

In-memory, always succeeding rebases are just really nice.

[stouset]

And also you can just… edit a commit. It’s not some special side effect of a certain flag to a different command. You can just say “gosh I really wish I’d made some changes here” and either move changes in, or just jump in and live-edit it directly.

It’s really a completely different way of thinking, but shockingly, one that essentially directly maps to what your actual intentions are.