I'm one of the weirdos that still holds on to mercurial as I genuinely prefer it's methods and workflow to git most of the time.
How the author describes handling work trees is exactly how they work in hg, and I find it enormously convenient vs the way that git by default really wants you to branch with work trees.
How I use them: My big expensive mechanical keyboard collection is mostly using QMK firmware. For whichever keyboards I'm currently using, I have a git worktree per-keyboard.
It would be useful to mention that
doesn't specify a reset mode, so the default mode --mixed is used. I prefer to use which leaves both the working tree and index unchanged.I'm one of the weirdos that still holds on to mercurial as I genuinely prefer it's methods and workflow to git most of the time.
How the author describes handling work trees is exactly how they work in hg, and I find it enormously convenient vs the way that git by default really wants you to branch with work trees.
How I use them: My big expensive mechanical keyboard collection is mostly using QMK firmware. For whichever keyboards I'm currently using, I have a git worktree per-keyboard.
Note that, since the 2.55.0 release this June, git offers "instant fixup" as "git history fixup <SHA>"
https://git-scm.com/docs/git-history
I was going to say it is funny that git without staging, stash and branches is really close to the philosophy of jujutsu.
Then I found the article links to jj homepage