Re: my git problem

[Carl Worth <cworth@cworth.org>]

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

On Mon, 28 Apr 2008 12:21:17 -0700 (PDT), Linus Torvalds wrote:
> On Mon, 28 Apr 2008, Andrew Morton wrote:
> > I'd have expected git-log to operate on the same patches as git-diff.
>
> No, not at all.
>
>  - "git log" shows each commit in a range.
>
>  - "git diff" shows just the difference between two states.
>
> The two have nothing in common. One operates on lots of individual commits
> (git log) individually, while the other one fundamentally operates on just
> two end-points (git diff).

Yes, the two operations are internally operating on different things,
(exactly as described).

> And "a..b" and "a...b" means two totally different things for the two
> totally different operations.

But the internal difference doesn't justify the totally different
meaning of "a..b" and "a...b" for these two operations. And in the
rest of your message you didn't justify the difference at all, (just
the fact that there *can* be a difference).

As a concrete example, I often want to view a series of patches that
is unique to a branch. I can easily do that with:

	git log -p a..b

Now, if I want to view basically the same information, but in a
"combined" view, (a single patch from the beginning to the final
state), I have to instead do:

	git diff a...b

And that's the part that's really confusing people, I think, (see
Andrew Morton running into the problem here, and Havoc Pennington
elsewhere). Conceptually, "a..b" is a way to say "the commits that are
unique to 'b' compared to 'a'", and that works great for git-log. But
when a similar concept is often desired for git-diff it's spelled
"a...b" instead. What's the justification for that? (Other than
historical accident.)

Meanwhile, you could even point to a similar case with the opposite
forms of each command. That is, one can see a series of patches with:

	git log -p a...b

And again, one can get get basically the same information in a
combined, single-patch form with:

	git diff a..b
or:	git diff b..a

depending on which direction one would like the combined version to be
in. Again, why the opposite syntax for basically the same information?

So git-log and git-diff are consistent in not treating the ".." and
"..." syntax uniformly, but I can't see any good justification for
that.

I don't think this second case is causing much problem. The symmetric
difference that's described by "git log a...b" isn't something I end
up needing very often, anyway. Meanwhile, a single patch between two
arbitrary states is extremely common, but I've always expressed that
naturally as "git diff a b", (by analogue with good old "diff fileA
fileB"), and never felt a need to spell this command as "git diff
a..b".

So, I do think the handling of ".." and "..." in git-diff is
objectively backwards compared to the way that git-log, git-rev-list
and everything else treat these operators.

I don't know what can be done to fix this now, though. Just expect
users to get confused, and then try to get them to drill "git log
a..b" and "git diff a...b" into their wee little brains.

Or maybe go Elijah's route and invent a new top-level command name in
which issues like this can get fixed. (I've been lukewarm on the idea
after watching the cogito attempt eventually be abandoned. I'd really
much rather see Elijah's ideas get pushed down into git itself for the
most part. But it's tough when backwards-compatibility prevents fixing
some things that are obviously confusing people.)

-Carl

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