On Thu, Dec 17, 2015 at 7:33 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Christian Couder <christian.couder@xxxxxxxxx> 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.
Yeah, I could just discard and recreate the UC from scratch if the
actual worktree and the root of the UC 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.
I am ok with that, though I worry a bit about some people having a
setup where they always use a worktree that is not one level above the
.git directory.
--
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