On Fri, Dec 21, 2012 at 11:43 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > On 12/21/2012 06:12 PM, Junio C Hamano wrote: >> "diff" is always about two endpoints, not the path that connects >> these two endpoints (aka "range"), and when you want to "diff" >> between two commits, you say "diff A B". "A..B" happens to be >> accepted as such only by accident (e.g. the old command line parser >> did not have a reliable way to tell "^A B" and "A..B" apart), not by >> design. Off topic: I also find it hard to wrap my head around what diffing against a negative revision would mean. Looking at the result of running it, it seems to be the same as diffing against a positive one. >> >> side note: incidentally, now we have rev_cmdline_info support, >> we could start deprecating "diff A..B" syntax. > > I often find myself using "git diff A..B" syntax when using the command > line history because the previous command used "A..B"; e.g., > > git log A..B > git diff A..B The problem with this, to me, if it wasn't clear, is that "git log A..B" shows you is new _since B branched off from A_, while "git diff A..B" shows you what has changed _between A and B_. >> Actually, in many places where the command line parser knows it >> wants a single point, and never a range, we should be able to apply >> the "A...B as a notation to specify a single point" rule. >> >> Of course you could come up with a symbol other than "..." for that >> purpose, and migrate the current "git checkout A...B" special case >> to use that other symbol, but that would be more work and also you >> would need to retrain existing users. > > OTOH making A...B sometimes mean a range and sometimes a merge-base > (depending on context) adds a confusing non-uniformity, and also has the > disadvantage of making merge-base shorthand unavailable in contexts that > allow a range. And making it unavailable in contexts where the command was not specifically implemented to support it. I'm sure there are many scripts out there that use "git ... $(git merge-base A B) ..." that could be simplified if rev-parse could resolve a merge base. > OTOOH git already has so many notations that can be used on the command > line; inventing yet another one would make it that much more overwhelming. Agreed. -- 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