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:
pgpPmrVXjhy2L.pgp
Description: PGP signature
