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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html