On Sat, Dec 14, 2013 at 3:43 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > 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. Link count goes down to 1 if I move the worktree to a different filesystem and it's not safe to remove $GIT_SUPER_DIR/repos/<id> in this case, I think. > 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. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html