Jonathan Nieder <jrnieder@xxxxxxxxx> 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 >> 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 ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html