Arthur Etchells <adetche...@gmail.com> writes: > git diff <commit>..<commit> > and > git diff <commit> <commit> > both succeed > however > git diff <commit>:<path>..<commit>:<path> > fails while > git diff <commit>:<path> <commit>:<path> > succeeds > ... > It seems logical to support the '..' syntax in both for consistency.
"git diff A..B" is an illogical thing to say in the first place. It only happens to work by historical accident, and for that "it used to work like so from the beginning, do not break backward compatibility" reason, we have kept it working. But you are better off unlearning it to keep your sanity when learning git as a new user. The dot notation is about a range. A..B talks about the set of commits that are ancestors of B but not ancestors of A. $ git log A..B makes perfect sense to show such a range. But "diff" is about "comparing two endpoints". There is nothing "range" about such a comparison. When you compare the state at A and at B, you do not even look at anything in between. That is why the canonical way to say it is $ git diff A B and not $ git diff A..B ;# WRONG. DO NOT DO THIS. And <commit>:<path> is a way to name an entity at <path> in the tree recorded in the <commit>. Typically you name a blob, not a tree that represents a subdirectory, with this syntax. Now, B1..B2, when B1 and B2 are blobs (or anything that is not commit-ish), does not make sense even as a range, and such a request is detected as an error at the syntactic level (i.e. without even starting to "compare"). $ git diff HEAD:Makefile..HEAD~4:Makefile ;# WRONG. DO NOT DO THIS. If you want to compare two blobs, you can do so with the canonical "compare two things" syntax. $ git diff HEAD:Makefile HEAD~4:Makefile -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html