On Sun, Sep 09, 2018 at 07:19:51PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> And then I turn that into:
> >>
> >> # @{u} because I happen to be on 'master' and it's shorter to type
> >> # than origin/master...
> >> git range-diff @{u} 38b5f0fe72...718fbdedbc
> >
> > I don't understand what you want with that @{u} or 'origin/master' in
> > the first place. It's unnecessary, the three-dot notation on its own
> > works just fine.
>
> Maybe I've been using the wrong mode all along, I passed over by habits
> from tbdiff, which were surely copy/pasted from somewhere.
>
> Looking at the git-range-diff manpage though it recommends <base> <rev1>
> <rev2> over <rev1>...<rev2> when the topic has been rebased, which is
> usually the case for e.g. a topic that's submitted to git.git (usually
> be the time feedback has been gathered & a re-submission has been made
> Junio has pushed another "master").
>
> So isn't "<base> <rev1> <rev2>" the right thing to use over
> "<rev1>...<rev2>" for git.git use? I think so, but I'm not sure.
The problem with <rev1>...<rev2> is that it finds the actual merge base,
not the beginning of the topic. So if you have a 5-patch topic, but the
first two patches weren't changed in the rebase, it won't show them at
all! I made this mistake in [1], for example.
For a force-push, though, you may not care about seeing the topic as a
whole, and that mid-topic merge-base could be just fine. So pasting just
the "A...B" works.
I don't think your "@{u} A...B" makes any sense. You're giving _two_
bases, which is weird. But even if you wanted to ignore the "..." base
as a convenience to users of fetch, @{u} does not necessarily have
anything to do with the @{upstream} of the topic at "A". You really want
branch@{u}, which is on a separate part of the fetch output line (and
your branch@{u} and the remote's are not necessarily the same, either;
in this case you probably do not even have that branch checked out).
-Peff
[1] https://public-inbox.org/git/[email protected]/
