Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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?
