Junio C Hamano wrote: > - Do we want to record where the working tree directory is in > $GIT_SUPER_DIR/repos/<id> somewhere? Would it help to have such > a record?
That could be nice for the purpose of garbage collecting them. I fear that for users it is too tempting to remove a worktree with "rm -rf" without considering the relationship from the parent repo that might be making walking through all reflogs slower or holding on to objects no one cares about any more. I imagine it would work like this: 1. At worktree creation time, full path to the working tree directory is stored in $GIT_SUPER_DIR/repos/<id>. 2. "git gc" notices that the worktree is missing and writes a file under $GIT_SUPER_DIR/repos/<id> with a timestamp, saying so. 3. If the worktree still hasn't existed for a month, "git gc" deletes the corresponding $GIT_SUPER_DIR/repos/<id> directory. Problems: * What if I move my worktree with "mv"? Then I still need the corresponding $GIT_SUPER_DIR/repos/<id> directory, and nobody told the GIT_SUPER_DIR about it. * What if my worktree is on removable media (think "network filesystem") and has just been temporarily unmounted instead of deleted? So maybe it would be nicer to: i. When the worktree is on the same filesystem, keep a *hard link* to some file in the worktree (e.g., the .git file). If the link count goes down, it is safe to remove the $GIT_SUPER_DIR/repos/<id> directory. ii. When the worktree is on another filesystem, always keep $GIT_SUPER_DIR/repos/<id> unless the user decides to manually remove it. Provide documentation or a command to list basic information about $GIT_SUPER_DIR/repos directories (path to worktree, what branch they're on, etc). (i) doesn't require any futureproofing. As soon as someone wants it, they can implement the check and fall back to (ii) for worktrees without the magic hard link. (ii) would benefit from recording the working tree directory as a possibly unreliable, human-friendly reminder. > - How would this interact with core.worktree in .git/config of that > "super" repository? Eek. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html