> To make it overcomplicated for git just to fake a point doesn't do it for me
I have experienced this exact scenario hundreds of times using git over the past two decades. I’m in the middle of some work, I realize I need to task switch to do some other work, then the work that was mid-flight should depend upon that interim thread of changes.
In git it is doable but it is a process, and one that is easily derailed (oh god a chain of failed automatic rebases) that requires keeping state in my head. In jj it is so trivial it doesn’t even register that I did something interesting or special, except when I remember how awful it would have been doing that in git.
It took me a number of years of working with git to realize it really really wants you to squash things. Especially if you're sharing branches.
git lets you create as complicated a commit tree as you want, and lets you do merges so you can have a separate commit where multiple changes come together, but realistically it really only works if you use it for a rebase workflow in your branches, squashing all changes into a single commit each time. Merge is an outlier when you need a more powerful tool to join branches but want to keep both of the originals still intact. But that shouldn't be your everyday workflow or you're guaranteed to end up with an unreadable, untraceable, and unmanageable commit graph.
Someone should let Linus know that git prefers this workflow. Someone should also let the maintainers of git itself know as well. Both happily employ a merge-based workflow.
What’s actually the case is that your workflow seems best with squash merging. There are a lot of project and teams where this is not the case.
Yes, there are a million first-party and third-party bandaids you can use on top of git to try and approximate a sensible workflow. I was a heavy user of `git-revise`.
All of these workarounds just… don't exist in jj, nor do they need to.
It’s not a bandaid, it’s working on two features which should be done on two separate clones. Worktrees avoid having to fully clone the repository, which is cool, but I’d use multiple clones if this did not exist.
I have experienced this exact scenario hundreds of times using git over the past two decades. I’m in the middle of some work, I realize I need to task switch to do some other work, then the work that was mid-flight should depend upon that interim thread of changes.
In git it is doable but it is a process, and one that is easily derailed (oh god a chain of failed automatic rebases) that requires keeping state in my head. In jj it is so trivial it doesn’t even register that I did something interesting or special, except when I remember how awful it would have been doing that in git.
> You're going to squash rebase at the end anyway
No? I’m not?