Git work-tree and Git note are two of the most slept-on features of Git. Incredibly useful, and easy to use iff you are using the command line. For some reason, neither are often supported by third-party tools, even relatively fully featured ones like Sourcetree (well, work-trees are kinda supported, but you need to make the work-tree in the CLI, then add it as repository on Sourcetree). Which is incredibly frustrating when trying to pitch a useful workflow to the rest of the team if that’s their primary mode of interaction with Git.
Magit seems to support worktrees really well, allowing you to list worktrees, create/delete them, and even allows you to create a new pull-request worktree if you have magit-forge setup (i.e. it will create a new worktree from a pull-request on the repository, extremely useful if you’re a maintainer).
Any tutorials? It’s not obvious if I have to clone the whole repo into the new worktree or if I can have different parts of a repo at different commits without creating new directories.
I’ve had a good time using git worktree to make a separate checkout for every feature branch at jobs that use Github’s PR workflow. I usually have a directory git/main with checkouts of the main branches of each project for code search and general poking, and a git/branch directory with in-progress feature branches, whether mine or ones I’m reviewing or whatever. As a bonus I forget less about work in progress this way as there’s a checkout of it in git/branch.
Unfortunately these are still not quite first class. In particular, there is one global git stash, which is inconvenient. And while you can use worktrees as submodules, they tend to get wiped out by rebase, necessitating a manual fixup.
Indeed. My interpretation, though (as a rebase addict) is that it’s the stash that’s not a first class citizen. If git tells me to commit or stash my work because I’m rebasing or changing branch, I just git commit -am stash. That’s my stash. It follows the branch, gets rebased with the branch, and I can have a series of such unfinished commits that would otherwise conflict if I tried to work on them one by one (instead, I can work on the whole series at once by squashing fixups into them). I don’t know what problem the stash solves that commits don’t solve better.
submodules tend to get wiped out by rebase
I think the general problem is that git lacks a stable commit id (if they only tend to get wiped, it’s because unreferenced commits get garbage collected eventually). I mentioned it as a programming breakthrough we need. One solution used by Gerrit is to have a change-id field in the commit message.
I think the general problem is that git lacks a stable commit id (if they only tend to get wiped, it’s because unreferenced commits get garbage collected eventually). I mentioned it as a programming breakthrough we need. One solution used by Gerrit is to have a change-id field in the commit message.
Sorry, perhaps I was unclear. I’m specifically referring to when you have git submodules which are worktrees. If you rebase across a change in the submodule commit, git will try to undo the checkout, but it will break the worktree. You end up with a submodule which is broken and has to be manually fixed (e.g. by editing the .git file or by running git worktree repair from the parent module).
A slight digression, but: ooh, are you using Chromium’s¹ new copy link to highlight feature? The way your link highlights the relevant part is good stuff. (And on a ~2500-word Git manpage it’s downright invaluable.)
¹ Link goes to Vivaldi docs because I know they have an announcement. But this feature has been in Chromium for more than year already, IIUC.
Ah, git worktree. I have done some incredibly stupid things with worktrees.
Git work-tree and Git note are two of the most slept-on features of Git. Incredibly useful, and easy to use iff you are using the command line. For some reason, neither are often supported by third-party tools, even relatively fully featured ones like Sourcetree (well, work-trees are kinda supported, but you need to make the work-tree in the CLI, then add it as repository on Sourcetree). Which is incredibly frustrating when trying to pitch a useful workflow to the rest of the team if that’s their primary mode of interaction with Git.
I am curious: What do you use git notes for?
GitHub once supported notes but they removed that feature. I never used them and I do not really see much point in using them.
Magit seems to support worktrees really well, allowing you to list worktrees, create/delete them, and even allows you to create a new pull-request worktree if you have magit-forge setup (i.e. it will create a new worktree from a pull-request on the repository, extremely useful if you’re a maintainer).
Any tutorials? It’s not obvious if I have to clone the whole repo into the new worktree or if I can have different parts of a repo at different commits without creating new directories.
I’ve had a good time using git worktree to make a separate checkout for every feature branch at jobs that use Github’s PR workflow. I usually have a directory git/main with checkouts of the main branches of each project for code search and general poking, and a git/branch directory with in-progress feature branches, whether mine or ones I’m reviewing or whatever. As a bonus I forget less about work in progress this way as there’s a checkout of it in git/branch.
Unfortunately these are still not quite first class. In particular, there is one global git stash, which is inconvenient. And while you can use worktrees as submodules, they tend to get wiped out by rebase, necessitating a manual fixup.
Indeed. My interpretation, though (as a rebase addict) is that it’s the stash that’s not a first class citizen. If git tells me to commit or stash my work because I’m rebasing or changing branch, I just
git commit -am stash. That’s my stash. It follows the branch, gets rebased with the branch, and I can have a series of such unfinished commits that would otherwise conflict if I tried to work on them one by one (instead, I can work on the whole series at once by squashing fixups into them). I don’t know what problem the stash solves that commits don’t solve better.I think the general problem is that git lacks a stable commit id (if they only tend to get wiped, it’s because unreferenced commits get garbage collected eventually). I mentioned it as a programming breakthrough we need. One solution used by Gerrit is to have a change-id field in the commit message.
Sorry, perhaps I was unclear. I’m specifically referring to when you have git submodules which are worktrees. If you rebase across a change in the submodule commit, git will try to undo the checkout, but it will break the worktree. You end up with a submodule which is broken and has to be manually fixed (e.g. by editing the
.gitfile or by runninggit worktree repairfrom the parent module).A slight digression, but: ooh, are you using Chromium’s¹ new copy link to highlight feature? The way your link highlights the relevant part is good stuff. (And on a ~2500-word Git manpage it’s downright invaluable.)
¹ Link goes to Vivaldi docs because I know they have an announcement. But this feature has been in Chromium for more than year already, IIUC.