Re: [PATCH v2 0/3] rev-parse and "--"

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 9, 2013, 20:48 UTC
Message-ID: <xmqqob4pycmv.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20131209191224.GR29959@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 17 quoted lines

> Junio C Hamano wrote:
>
>>>                                      So maybe we are doing a favor by
>>> calling out the problem; if they want a rev, they should be using
>>> "--verify" (or "--").
>>
>> I tend to agree with the reasoning in the last sentence. Let's cook
>> it for a while and see what happens.
>
> Isn't this essentially breaking a contract that would have been relied
> on by any script that used "git rev-parse HEAD~3..HEAD"?  Worse, it's
> breaking that contract in a way that no one would notice until they
> are asked to manipulate a worktree with a file named 'HEAD~3..HEAD'
> --- in other words, the breakage it introduces is painfully subtle.
>
> I agree that "git rev-parse HEAD" is better written as "git rev-parse
> --verify HEAD" and hence not so much worth worrying about,

I do not share the "with --verify is better hence no problem" reasoning. My "not so much worth worrying about" comes solely from a hunch that nobody has "HEAD~3..HEAD" in their working directory, and if somebody has one, then they must be using "--verify" (or a clarifying "--"), because their "git log" and whatever they use "git rev-parse HEAD~3..HEAD" for would behave very differently otherwise.

So it is not merely "--verify is better"---in a situation where the backward incompatibility matters, I doubt the existing behaves sensibly in the first place.

But if we cook it for a while, I suspect that we will find more and more breakages of expectations in the existing scripts in and out of the tree; in general, I hate _any_ change, and I do not mind dropping it ;-).