Re: Three dot notion used inconsitent?

[Michael J Gruber <git@drmicha.warpmail.net>]

Andreas Schwab venit, vidit, dixit 18.11.2015 18:49:
> Lars Schneider <larsxschneider@gmail.com> writes:
> 
>> git diff branchA...branchB
>> --> gives me the diff between (the common ancestor of A and B) and B. That means I never see changes on branchA.
>>
>> git log branchA...branchB
>> --> gives me the commits reachable from A and B. That includes changes from branchA.
>>
>> Is this because of a design decision that I do not (yet) understand or is this inconsistent for historical reasons?
> 
> git diff operates on two revisions.  That is inherently incompatible
> with the usual meaning of A...B and A..B, which are set operations on
> the revision history.  That git diff accepts this syntax is only for
> convenience.

That convenience can be a bit misleading, though, as the OP points out.
Just to spell this out because the other response (not the one I'm
replying to) could be misunderstood:

git diff A..B is the diff between (the trees in commits) A and B. It
will show you the "changes" that are only in A with "-", the changes
that are only in B with "+" - that is, if you want to think about diffs
as "positive changes" to a "virtual common base tree".

[ If p are the plus lines and m the minus lines, the diff says
    B = A + p - m = (A-m) + p
<=> A = B - p + m = (B-p) + m
<=> B-p = A-m (virtual common base tree) ]

git log A..B will show you all commits that are in (=reachable from) B
but not in A. That is, it will show you all commits between the "most
recent" common ancestor (let's call it C) and B (including B), but not
those between C and A (and not A either).

git log A...B will show you all commits "specific to A and B", i.e.
those between C and B and those between C and A (including A and B,
excluding C).

git diff A...B will show you the diff between C and B.

So, both "diff A..B" and "log A...B" show changes/commits introduced by
A only or B only.

"diff A...B" and "log A..B" show changes/commits introduced by B only.

Maybe there's a way to think about these that makes them actually look
consistent - the only one that I can think of is the actual
implementation (we need to compute the merge base for both "..."
commands), but that's a really bad argument for a user facing notation.

Michael