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

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 7, 2018, 10:01 UTC
Message-ID: <CACsJy8CCHzysHM4pJpY1Xz-8QLzRF5zj=+cjNifsHRCMUci8Fg@mail.gmail.com>
In-Reply-To: <CAPig+cRGMEjVbJZKXOskN6=5zchisx7UuwW9ZKGwoq5GQZQ_rw@mail.gmail.com>

On Sat, Mar 3, 2018 at 5:05 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:

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

No, we need to re-normalize paths before comparing anyway to be safe. I don't think I had any special reason for using absolute path either, except that dealing with it is a bit easier than relative one.

Show 11 quoted lines

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

True. We can be a bit more aggressive and check it anyway at command startup (once we can peek into the main .git dir, we know where this linked worktree is supposed to be). Or perhaps we can do this in "gc --auto" (even though gc may end up not doing any maintenance job). This command is usually called on heavy commands, adding one more check should not hurt.

Show 12 quoted lines

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

Yeah I'm a bit hesitant to break that file format. Many tools ignore our programs and peek inside anyway, I think magit is one of them.

-- 
Duy