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