Re: "git worktree repair" modifies the wrong repository
- From
- Russell Stuart <russell+git.vger.kernel.org@stuart.id.au>
- Date
- Sep 19, 2024, 11:40 UTC
- Message-ID
- <4781ff6e-c20a-4340-851b-c9d324d1fac8@stuart.id.au>
- In-Reply-To
- <CAPig+cTkpLLoTxTa-8xfycNGFibN_M71+kkHtT-wgp6HRPi-aw@mail.gmail.com>
On 19/9/24 20:47, Eric Sunshine wrote:
Show 6 quoted lines
> The idea of relative paths has been discussed previously[*] but was > never implemented; although they may help some cases, they break > other cases or at least make the other cases more difficult. For > instance, relative paths only help if the main and linked worktrees > move together in some uniform fashion, but don't help if they move in > distinct ways.
If breaking when moved is the criteria, then absolute paths always break. Relative paths break slightly less often. So it seems to me relative paths are an improvement - but not a fix.
It's always possible to break something by moving the wrong thing. For example moving the .git directory in a normal repository would create a mess. Yet, unlike moving worktrees (most?) people do not attempt to move the .git directory in illegal ways. They always copy/more copy the entire repository. It's intuitively obvious if you keep the .git directory in the same relative position, it will work.
So my uniformed guess on how to "fix" the problem of people moving/copying worktrees is to make equally obvious they must remain in the same relative position to the parent. One way to do that is to use the same structure hg uses, which is the child worktrees must all be in the one common parent directory, and the parent directory contains the .git metadata. It then becomes self-evident you can only more/copy the entire thing - not bits of it.
> [*] The previous discussion was in the context of an earlier > implementation of git-worktree, long before there was a "repair" > subcommand. In fact, the very original implementation of linked > worktrees
Thanks. The starting point of "linked git directories" (I presume to save on metadata storage?) explains a how worktrees ended up where they have.
Interestingly, people (including me as it happens) start out by trying to emulate the hg approach using a single parent directory to hold a bare repository, and the child worktree directories. Then they discover bare repositories mangle the remote links, and give up on the idea. In my case I then tried moving/copying the worktrees as a group using "git worktree repair" to fix the mess, which eventually lead to this email :)
Others have published of hacks / tricks that try to solve problem in other ways, eg: https://github.com/Kristian-Tan/git-worktree-relative
None of them work very well. Going on what Google throws up, moving worktrees remains a commonly felt pain point.
-- Regards, Russell Stuart