Re: Updated Kernel Hacker's guide to git

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

On Thu, 21 Dec 2006 10:23:30 -0800 (PST), Linus Torvalds wrote:
> In short, for git diff (and ONLY) git diff, all of these are the same:
>
> 	git diff a..b
> 	git diff a b

I admit that I had had never passed a range of commits to git diff,
nor even given any thought to what it might do, but I definitely find
the above very surprising---and not necessarily very useful. Why is
anyone ever typing those two dots here if they have no effect on the
result?

> It basically all boils down to:
>
> 	"git diff" is special
>
> exactly because unlike almost ALL other git commands, "git diff" does not
> work on a _list_ of commits, it only works on two end-points. That means
> that the "list operations" actually end up meaning something else for git
> diff than they do for "git log" and friends.

Yes, "git diff" can only work on two end points. So a command like:

	git diff a b

is really easy to understand. And if the user wants to compare those
two points, why would the user ever provide them with any other
syntax?

In other words, what's the advantage of "git diff" accepting a special
syntax for a range ("a..b") and yet not actually doing anything
special with it?

In particular, the operation that would be interesting here is what
one can get with:

	git diff $(git merge-base a b) b

so why isn't _that_ the operation that is accessed with the syntax of:

	git diff a..b

Said another way, if "git log a..b" displays a range of commits, why
doesn't "git diff a..b" display the diff from the beginning of that
range to the end?

Of course, all the warnings you gave about what "git diff" would do
in the case of various criss-cross merge scenarios would still apply.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]