Re: Itches with the current rev spec

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 25, 2013, 05:54 UTC
Message-ID: <CALkWK0mr55QwrcsvyeRzq1K0RgEB7YOxMRhz2kjckRGZe-Tz7A@mail.gmail.com>
In-Reply-To: <CALkWK0n97VLtiR96VEy86645NVoDL2rS-g7LBuLb=JpncdH6VA@mail.gmail.com>

Ramkumar Ramachandra wrote:

Show 8 quoted lines

> 3. Even though I lashed out strongly against 'git diff A..B' because
> of inconsistency, I can't say that it's not useful (omit specifying
> HEAD on one side).  If we were to start over today, I would argue that
> 'git diff A ^B' and 'git diff B ^A' be handled as special cases to
> mean 'git diff B $(git merge-base A B)' and 'git diff $(git merge-base
> A B) B' respectively.  The normal 'git diff A B' should have nothing
> to do with this.  Plus, 'git diff A...B' is really an eyesore.  So I
> ask again: what can be done to improve the situation?

Okay, so my solution to this is:

1. Change the meaning of 'git diff A..B' (and A ^B, ^A B for
consistency).  Existing users might be using 'git diff master..' on
their feature branches to get meaningful output, and this will not
change.  'git diff featurebranch1..' on another feature branch doesn't
give meaningful output anyway, and I find it hard to believe that
users will complain if we change the meaning of this.  Okay, maybe we
want to do it in git 2.0?

2. Document (1) properly in gitrevisions.txt.

3. Deprecate 'git diff A...B'.

What do you think?