Re: [PATCH 3/5] worktree: teach "repair" to fix outgoing links to worktrees

[Eric Sunshine <sunshine@sunshineco.com>]

On Thu, Aug 27, 2020 at 1:14 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > Therefore, teach "git worktree repair" how to repair broken or outdated
> > .git/worktrees/<id>/gitdir files automatically. (For this to work, the
> > command must either be invoked from within the worktree whose gitdir
> > file requires repair, or from within the main or any linked worktree by
> > providing the path of the broken worktree as an argument to "git
> > worktree repair".)
>
> Would git "work" in a corrupt worktree whose gitfile is broken, in
> the sense that it notices that the cwd is the top of the working
> tree of a secondary worktree?

No. For this repair to work, the gitfile in the linked worktree must
be intact; it must be pointing back at the .git/worktrees/<id>
directory so that "git worktree repair" can repair the corresponding
.git/worktrees/<id>/gitdir file.

Making it "work" for the case when both the worktree's gitfile is
broken and .git/worktrees/<id>/gitdir is broken would require an
enhancement like what you mentioned in your review of patch [2/5] in
which the user would manually specify the location of the main
worktree (or repository). That is something which can be added, but I
wanted to keep this initial implementation simple.

> Hmph, if the secondary is _moved_, how would "worktree repair $path"
> would know which <id> the $path corresponds to? Would we just cull
> all the <id> that do not point at working secondary worktrees and
> add the $path as if it were a new one by allocating a new <id>, or
> reusing a randomly chosen <id> that points at a non-existing
> location?

Since this can only work if the linked worktree's gitfile is intact,
and since the content of the gitfile is the path .git/worktrees/<id>,
"git worktree repair" knows the exact <id>, thus the precise
.git/worktrees/<id>/gitdir file to repair. It is deterministic; there
is no guessing about <id>, and there is no creating a new <id>
magically (though I did consider additional repair cases but opted
against them for the initial implementation).