On Tue, 18 Apr 2006, Junio C Hamano wrote: > Linus Torvalds <torvalds@xxxxxxxx> writes: > > > git diff v0.99.6:git-commit-script..v1.3.0:git-commit.sh > > This is interesting. > > Yet to be born "internal diff". Should I start one, or are you > already hacking on it? I'm not working on it, but I might get back to it if nobody else beats me to it. Probably not in the next few days, though, so if you feel the urge, please do look into it. Anyway, the above syntax would actually work even with the current external diff, because with my suggested patch we get: git-rev-parse v0.99.6:git-commit-script..v1.3.0:git-commit.sh resulting in 01c73bdd08e075d650e58664650bcd7fe1cd1551 ^a2455b0f8ff1582248b0678b9c85b2f064d972c4 (which are just the SHA1's for the object), and then the external diff will just see that it's two commits, so it decides to just feed them directly into git-diff-tree. So if we added the test for "are the objects two commits" to git-diff-tree and diffed them directly, it would all "just work". But you're certainly correct in stating that it would be _cleaner_ to do it with a internal "git diff" command. Everything should be perfectly set up by just calling the regular "setup_revisions()", and looking at the "rev.pending_objects" list. 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. Linus - : 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