Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 9, 2017, 11:18 UTC
Message-ID: <CACsJy8D1Pf6zTS8gqv5Gq6xMxNNbDrTpKHGADRMKNqW1FAzZvA@mail.gmail.com>
In-Reply-To: <xmqqshou35zr.fsf@gitster.mtv.corp.google.com>

On Sun, Jan 8, 2017 at 4:38 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> Christian Couder <christian.couder@gmail.com> writes:
>
>> It feels strange that when I do things one way, you suggest another
>> way, and the next time in a similar situation when I do things the way
>> you suggested previously, then you suggest the way I did it initially
>> the first time...
>
> Perhaps because neither is quite satisfactory and I am being forced
> to choose between the two unsatifactory designs?  In any case, I
> mostly am and was pointing out the issues and not saying the other
> one is the most preferred solution in these threads.
>
> I think there should just be one authoritative source of the truth,

Either that, or we make sure all sources of truth are consistent. In this case, 'update --split-index' could update core.splitIndex if it finds that the config tells a different story. As a plumbing though, I rather leave update-index do simple things, even if it means the user has to clean up after it (or before it) with "git config -unset core.splitIndex". Another option is refuse to execute --split-index in the presence of (conflicting) core.splitIndex. We kind of force the user to keep all sources of truth consistent this way while leaving a back door ("git -c core.splitIndex= update-index") for those who need tools to recover from a bad case.

Show 12 quoted lines

> and I have always thought it should be the bit set in the index file
> when the command line option is used, because that was the way the
> feature was introduced first and I am superstitious about end-user
> inertia.  And from that point of view, no matter how you make this
> new "config" thing interact with it, it would always give a strange
> and unsatifactory end-user experience, at least to me.
>
> Perhaps we should declare that config will be the one and only way
> in the future and start deprecating the command line option way.
> That will remove the need for two to interact with each other.
>
> I dunno.

-- 
Duy