Re: [PYRITE] Status update and call for information.
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- May 24, 2008, 22:23 UTC
- Message-ID
- <200805250023.27440.jnareb@gmail.com>
- In-Reply-To
- <20080524195753.GB3745@dpotapov.dyndns.org>
On Sat, 24 May 2008, Dmitry Potapov wrote:
Show 11 quoted lines
> 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