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

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@sunshineco.com> writes:

> The .git/worktrees/<id>/gitdir file points at the location of a linked
> worktree's .git file. Its content must be of the form
> /path/to/worktree/.git (from which the location of the worktree itself
> can be derived by stripping the "/.git" suffix). If the gitdir file is
> deleted or becomes corrupted or outdated, then Git will be unable to
> find the linked worktree. An easy way for the gitdir file to become
> outdated is for the user to move the worktree manually (without using
> "git worktree move"). Although it is possible to manually update the
> gitdir file to reflect the new linked worktree location, doing so
> requires a level of knowledge about worktree internals beyond what a
> user should be expected to know offhand.
>
> 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?  I can imagine how it would work,
starting in one of the functioning worktrees so that git can locate
where the primary copy is, with end-user supplied path to a
directory that is supposed to be the top of the working tree of a
secondary worktree.

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?