Re: contrib/workdir/git-new-workdir broken in 1.7.10 after introducing gitfiles

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2012, 19:51 UTC
Message-ID: <xmqq397wzwwd.fsf@junio.mtv.corp.google.com>
In-Reply-To: <4F930043.1080506@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 9 quoted lines

> Opinions?
>
> ----8<-----
> Subject: [PATCH] git-new-workdir: Suggest unsetting the core.worktree setting
>
> Linking to a repository that has the core.worktree option set can only
> work when that core.worktree setting already points to the new-workdir.
> In all other cases strange things will happen, as new-workdir will be
> overridden by that setting.

As you analyzed correctly, core.worktree lets a GIT_DIR to declare that there is a single working tree associated with it. It fundamentally is incompatible with new-workdir, which is a hack to let more than one working tree associated with a single GIT_DIR.

I however do not think a simplistic "unset core.worktree" is a good suggestion, though, as we do not know why the original repository has that variable set pointing at somewhere. Blindly removing it will break the use of the original repository. If somebody _really_ wants to use new-workdir for whatever reason in such a setting, I would imagine that doing something like this:

 - Create a new repository somewhere that is an identical copy of the
   original repository's GIT_DIR, except for core.worktree dropped;

 - Turn the working tree original repository pointed with core.worktree
   into a "new-workdir" off of that new repository; and

 - When you want more "new-workdir"s, create them off of that new copy.

may work. But honestly speaking, "Do not use this hack---having more than one working tree is fundamentally incompatible with it", may be a more sensible message.