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

[Junio C Hamano <gitster@pobox.com>]

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

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