On Sat, 24 May 2008, Dmitry Potapov wrote: > On Fri, May 23, 2008 at 06:07:34PM -0700, Jakub Narebski wrote: >> >> On the other hand the a..b and a...b notation is matter of convenience >> (it is easier to use than "b ^a" or "a b --not $(git merge-base a >> b)"); perhaps allowing a..b and a...b notation for git-diff was an >> error... but it makes copy'n'paste easier... > > I believe that the error was how these operations were defined for diff. > I would rather expect to 'git diff a..b' to produce the accumulative > patch of 'git log -p a..b', but currently 'git diff a..b' is equivalent > of 'git diff a b', and this is redundant and confusing. I think "git diff a..b" and "git diff a...b" (which is cute hack) were created to allow copy'n'paste from git-fetch result messages, not only to git-log but also for git-diff; note that in case of git-fetch messages a..b is always fast-forward (a = merge-base a b). I think that both solutions for "git diff a..b", be it "git diff a b" or "git diff $(git merge-base a b) b" can be argued for, soe historical reasons (a...b was added later) and backward compatibility wins. > As to 'git diff a...b', it would be nice if it showed three way diff. > At least, it is how I would define them if I were writing some > front-end. At least "git diff --cc a...b" and "git diff -c a...b", i.e. diff as if there were a merge... although now that I look at it it seems to be more difficult than on first glance. -- Jakub Narebski Poland -- To unsubscribe from this list: 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
