Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)

From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jun 2012, #01; Sun, 3)
Date: Wed, 6 Jun 2012 20:17:36 +0200	[thread overview]
Message-ID: <CAMP44s2VGLj8kRih-95A0VDq86WKWHF3EhLvz0etyHHtP27qLA@mail.gmail.com> (raw)
In-Reply-To: <7vbokwmifp.fsf@alter.siamese.dyndns.org>

On Wed, Jun 6, 2012 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> The last remaining sticking point is what to do with the duplicated shell
>>> function.
>>
>> What is the problem with leaving it as it is; having it as a duplicate
>> function. It's not a *huge* maintenance burden, and it's a big problem
>> if the functions diverge.
>
> It is not even funny to see these two conflicting claims made in a
> single sentence.  Given that you are aware that it will cause a huge
> problem to the end users if they diverge,

What would be that *huge* problem?

Suppose __gitdir() in git-prompt.sh is never updated again; it won't
be any worst than it is currently, would it?

Sow what would be this _theoretical_ problem?

> I did not see anything like these.

Nor is it needed *right now*. You could release v1.7.11 without any of
these, and then v1.7.11.1 or even v1.7.12 with a solution; I bet
__gitdir() would not have changed by that point.

But more importantly; the world would not end.

> I think I've sent out a patch along the line of (1) in an attempt to
> help, but I do not recall you responded to it in any way.

I just saw it now, and I think it's unnecessary extra complexity.

> And the
> first thing you do is to complain. The maintenance burden could be
> made into "not huge", but what you are doing is to actively make it
> more burdensome than necessary.

I don't think it's needed *right now*. It's more important to fix the
dynamic loading, which is a *real problem* users are experiencing
*right now*.

>> I still plan to add a native helper for this, but I don't see what
>> that would block these patches.
>
> I do not want to see a native helper, if other approaches would
> equally work to prevent divergence from happening, in which case
> such a change to the core would be a useless code churn.

Feel free to reject my patches and implement whatever you want, but I
think this is the cleanest and simplest solution, and I will give it a
try. But not right now.

Cheers.

-- 
Felipe Contreras