Re: [PYRITE] Status update and call for information.

[Jakub Narebski <jnareb@gmail.com>]

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