On Fri, Mar 2, 2018 at 6:53 AM, Duy Nguyen <pclouds@xxxxxxxxx> 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.
