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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html