Linus Torvalds <torvalds@xxxxxxxx> writes: > Now, the thing that an internal "git diff" could do better is to notice > when it gets _one_ blob revision, and one filename, ie we could do > > git diff v0.99.6:git-commit-script git-commit.sh > > which parses as one SHA1 of a blob (put onto the rev.pending_objects > list), and one filename (in the rev.prune_data array). We could decide to > automatically do the "right thing" for that case too. The "right thing" is ambiguous, I am afraid. I think it would be natural to interpret the request as a diff between the blob from v0.99.6 and a random working tree file, which may not even exist in the index. However I suspect what you are getting at is to act as if the user said: git diff v0.99.6:git-commit-script HEAD:git-commit.sh Oh, another possibility is to act as if the user said git diff v0.99.6:this :git-commit.sh where "(empty):" would stand for "look up in the index, not in a tree". I think these are all valid interpretations and there are useful use cases (admittably the last one is "diff-cache --cached"). Unfortunatly, I do not think this parses well: git diff git-commit.sh v0.99.6:git-commit-script but you could always say: git diff -R v0.99.6:git-commit-script git-commit.sh - : 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