On Sat, Dec 14, 2013 at 3:43 AM, Jonathan Nieder <jrnie...@gmail.com> 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.
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

Reply via email to