Re: Worktree silently deleted on git fetch/gc/log

[Eric Sunshine <sunshine@sunshineco.com>]

On Fri, Mar 2, 2018 at 6:53 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> I'm going to improve it a bit in this case either way, I think I have
> some idea: (mostly to Eric) since worktree B is alive and kicking, it
> should keep at least HEAD or index updated often. We can delay
> deleting a worktree until both of these are past expire time.

Make sense.

> Also Eric (and this is getting off topic), I wonder if the decision to
> store absolute path in worktrees/../gitdir and .git files is a bad one
> (and is my bad).

Your original implementation of worktrees was able to recover
automatically when a worktree was moved (via 'mv', for instance). That
feature pretty much required recording an absolute path in the
worktree's .git file. When the automatic-recovery feature was dropped,
I suppose the need for absolute path in the .git file disappeared, as
well.

I can't presently think of a reason why gitdir needed/used an absolute
or normalized path. Was it because there was some need to compare such
paths?

> If we stored relative path in ".git" file at least, the worktree would
> immediately fail after the user moves either the linked checkout, or
> the main one. This should send a loud and clear signal to the user
> "something has gone horribly" and hopefully make them connect it to
> the last rename and undo that. "git gc" would have near zero chance to
> kick in and destroy stale worktrees.

It would detect if the main or linked worktree moved up or down one or
more directory levels or elsewhere.

It would not detect if the worktree directory was merely renamed.

Still, detecting some cases of breakage early may be better than not
detecting breakage at all.

Another idea may be to store the worktree's own normalized/absolute
path as a second line in its .git file. It could then immediately
detect any manual movement or renaming of itself. A minor concern,
though, is if there are any external tools reading that file directly
since they could be confused by the second line. Of course, such tools
hopefully would be using "git rev-parse --git-dir", so maybe it
wouldn't be a big deal. On the other hand, older versions of Git
itself would be confused by the second line, so perhaps the idea isn't
viable.

> Another bad thing about absolute paths, if you backup both main and
> linked worktrees in a tar file, restoring from the backup won't work
> unless you restore at the exact same place.
> Hmm?

Yep, that's an issue. An even simpler case is the somewhat common
usage pattern of creating worktrees within the main worktree (Dscho
has a number of times mentioned working like this, and I've done it
myself). In such a case, even just moving or renaming the main
worktree breaks the linked ones when absolute paths are in play.

So, yes, these issue argue for use of relative paths.