Re: [BUG] Highly inconsistent diff UI

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 24, 2013, 22:44 UTC
Message-ID: <CALkWK0=NWSZsARu9w0DwpEmJHKnvpB8yoNfEa31LDQA=cV-90Q@mail.gmail.com>
In-Reply-To: <7vvc7baahc.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 11 quoted lines

> How is it different from "git log master..rebase.autostash"?
>
>     git log A..B
>
> is already a perfectly fine way to spell your "A~B", which is
>
>     git log B --not $(git merge-base --all A B)
>
> when written in longhand [*1*], no?
>
> So I do not think your A~B helps "log".

They are equivalent if you use --all, which I didn't originally propose. I'll present a slightly contrived example, because I don't personally merge much in the real world:

pu is based on master~10. rebase.autostash is based on master~5 and master~3 merges in pu. I merge pu into rebase.autostash while working. Now, master..rebase.autostash will exclude commits reachable from master (and therefore pu), but master~rebase.autostash will show the commits in pu that I merged in.

Ofcourse, I now see that this is probably useless, and .. fits my bill.

When packaged with a good default for LHS (which .. currently doesn't have), it might be a slightly better candidate. I was thinking origin instead of [nearest-fork-commit].

> It does not help "diff" either, because we already have A...B and we
> are not going to remove it (people are used to what it means).

Yeah, the invention arose as way to find a replacement for this inconsistency.

> So I think your A~B is still a solution that is looking for a
> problem.

Yeah, so it looks like the problem is entirely a minor cosmetic detail: we're just clothing existing functionality with a consistent new refspec.

We might still want it.  I mean what are we losing?