Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 10, 2017, 21:17 UTC
Message-ID: <xmqqh941kanv.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqy3xgrlvh.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 31 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> On Mon, Feb 06, 2017 at 02:34:08PM -0800, Junio C Hamano wrote:
>>
>>> * sk/parse-remote-cleanup (2017-02-06) 1 commit
>>>   (merged to 'next' on 2017-02-06 at 6ec89f72d5)
>>>  + parse-remote: remove reference to unused op_prep
>>> 
>>>  Code clean-up.
>>> 
>>>  Will merge to 'master'.
>>
>> Hrm. Are the functions in git-parse-remote.sh part of the public API?
>> That is, do we expect third-party scripts to do:
>>
>>   . "$(git rev-parse --exec)/git-parse-remote.sh
>>   error_on_missing_default_upstream "$a" "$b" "$c" "$d"
>>
>> ? If so, then they may be surprised by the change in function signature.
>>
>> I generally think of git-sh-setup as the one that external scripts would
>> use. There _is_ a manpage for git-parse-remote, but it doesn't list any
>> functions. So maybe they're all fair game for changing?
>>
>> I just didn't see any discussion of this in the original patch thread,
>> so I wanted to make sure we were making that decision consciously, and
>> not accidentally. :)
>
> Ummm, yes, I admit that this was accidental.  I didn't really think
> of parse-remote as an externally visible and supported interface,
> but users have tendency to break our expectations, so, I dunno.

After sleeping on this, I doubt that the value of this "code clean-up" is worth the trouble of waiting to see if a third-party who dot sources parse-remote steps up, which may never materialize while the topic is cooking in 'next' and more importantly risking breakage on such a third-party.

Let's drop the topic and excise it from 'next' at the next version boundary.