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

[Mark Levedahl <mlevedahl@gmail.com>]

On 04/22/2012 12:41 AM, Junio C Hamano wrote:
> Junio C Hamano<gitster@pobox.com>  writes:
>
>> 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:
>> ...
>> may work.
>
> I am too lazy to try it out myself, but a hack something along the line
> of the attached patch _might_ turn out to work well.
>
> At least, it gives an incentive to people to update to more recent
> versions of git ;-)  I dunno.
>
> -- >8 --
> Subject: new-workdir: use its own config file
>
> Instead of letting a new workdir share the same config, we simply
> include the original config and override core.worktree in it.  This
> obviously changes the behaviour from the traditional workdir, by making
> any update to the config in a workdir private to that workdir and not
> reflected back to the original repository.  Because a workdir is
> supposed to be just a peek only window to check out a branch that is
> different from the main working tree, and you are not expected to modify
> the config file in any way (e.g. you do not create a new branch with
> remote configuration in a workdir), it may not be a huge issue.
>

This change will break my use of new-workdir, which is maintaining 
multiple checked out branches in separate directories, some with 
embedded modules, and being able to share changes and remote branches 
between them. These directories are time-consuming to set up, so the 
usually suggested approach of "git-checkout $other_branch" is not very 
useful. All of the workdirs are set up off of a common set of bare repos 
kept elsewhere.

There are other ways to share between multiple independent repositories 
on the same machine, but new-workdir is the simplest as there is no push 
/ pull / patch / am involved.

I think the "peek-only" use case is better supported by clone, which on 
a local machine does not copy the object store, and is of course 
well-documented and in core-git. Perhaps a better patch is to just 
suggest "clone" to the user who has core.worktree and/or submodules in use?

Mark