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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quite frankly, the discussion got pretty technical for me and I don't follow it.

I have just posted my current solution involving hard links instead
new-workdir script:
http://stackoverflow.com/a/10265084/84283

Also it links this discussion as a warning that new-workdir may not be
the right solution.

Anyways, thanks for your great job on git! Much appreciated.

On Sat, Apr 21, 2012 at 12:51 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jens Lehmann <Jens.Lehmann@xxxxxx> 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.
>
>
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]