Christian Couder <christian.cou...@gmail.com> writes:

> In the "git worktree" documentation there is:
>
> "If you move a linked working tree to another file system, or within a
> file system that does not support hard links, you need to run at least
> one git command inside the linked working tree (e.g. git status) in
> order to update its administrative files in the repository so that
> they do not get automatically pruned."
>
> It looks like git can detect when a worktree created with "git
> worktree" has been moved and I wonder if it would be possible to
> detect if the main worktree pointed to by GIT_WORK_TREE as moved.

As I personally do not find "moving a working tree" a very
compelling use case, I'd be fine if cached information is not used
when the actual worktree and the root of the cached untracked paths
are different.

If you are going to change the in-index data of untracked cache
anyway (like you attempted with 10/10 patch), I think a lot more
sensible simplification may be to make the mechanism _always_ keep
track of the worktree that is rooted one level above the index, and
not use the cache in all other cases.  That way, if you move the
working tree in its entirety (i.e. $foo/{Makefile,.git/,untracked}
all move to $bar/. at the same time), the untracked cache data that
was in $foo/.git/index, which knew about $foo/untracked, will now
know about $bar/untracked when the index is moved to $bar/.git/index
automatically.

--
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