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".

Advertising

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