On Sat, Dec 14, 2013 at 3:43 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > 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. I was thinking about doing something like this in "git prune" but manually. Your idea sounds nicer. > 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. We could store $GIT_SUPER_DIR as relative path. That way if you move it, you break it. When you fix it, hopefully you remember to fix the link in repos/<id> too Alternatively, the setup up code could be taught to verify that $GIT_SUPER_DIR/repos/id/<backlink> actually points to the current worktree. If not warn the user or something > * What if my worktree is on removable media (think "network > filesystem") and has just been temporarily unmounted instead of > deleted? Or we keep update a timestamp in repos/<id> to note the last used time of this worktree. "gc" or "prune" would warn about unused repos after a certain amount of time, do not remove them automatically. This could be iii. to your list below. > 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. This can still break with updating by creating a new version, then renaming it. Although I can't think why anybody (or anything) would want to do that on .git file. This does not work on Windows though. > 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). And on Windows, a new partition means a new drive, so it works there too. > > (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. I'll see if I can ignore core.worktree when $GIT_SUPER_DIR is set. If not, ban this use case :) -- 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