On 19/9/24 20:47, Eric Sunshine wrote:

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