Junio C Hamano wrote:
> 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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to