Jonathan Nieder writes:
>> 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;
>
> Alas, probably no, because nobody has "HEAD~3..HEAD" in their working
> directory. That's exactly the problem --
Junio C Hamano wrote:
> 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,
That's what makes it a problem. This change makes it very easy to
make
Jonathan Nieder writes:
> 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
>>
Jonathan Nieder wrote:
> Isn't this essentially breaking a contract
To clarify, if there were some strong motivation --- e.g. if this
were resolving some security problem --- then I would be all for
breaking compatibility in this way. What's confusing to me is that I
just don't see the motivati
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
Jeff King writes:
> Is it better for "rev-parse" to be more careful, and to behave more like
> the rest of git? Or is better to be historically compatible?
>
> One thing to note is that "git rev-parse HEAD" is slightly broken there
> already. Because "git rev-parse $some_branch" may do very diffe
On Fri, Dec 06, 2013 at 03:25:56PM -0800, Jonathan Nieder wrote:
> > commit=$(git rev-parse HEAD)
> >
> > I'm tempted to say that people who did that are stupid and wrong (and
> > ugly, too). They should probably be using "--verify" in this case. But
> > it has been that way for a long time, and
Jeff King wrote:
> Patch 3 is the revised version of this patch which notices ambiguity.
> However, I'm having second thoughts on it. I think it's the right thing
> to do if you want to help people build something like "git log"
> themselves. But it does mean that we are breaking somebody who does
On Fri, Dec 06, 2013 at 04:15:09PM -0500, Jeff King wrote:
> If you have both a file and a branch named "foo", running:
>
> git log foo
>
> will complain. We should do the same in rev-parse, and
> demand that it be disambiguated with:
>
> git rev-parse foo --
>
> or
>
> git rev-parse --
9 matches
Mail list logo
