On Sun, Jan 8, 2017 at 4:38 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Christian Couder <christian.cou...@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.
> 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
