Re: [PATCH 4/4] fetch: opportunistically update tracking refs

From: Jeff King <peff@peff.net>
Date: May 16, 2013, 03:37 UTC
Message-ID: <20130516033748.GC13296@sigill.intra.peff.net>
In-Reply-To: <87r4hcedra.fsf@linux-k42r.v.cablecom.net>

On Sun, May 12, 2013 at 11:41:45AM +0200, Thomas Rast wrote:

Show 16 quoted lines

> >> We miss an opportunity to update "refs/remotes/origin/master"
> >> (or whatever the user has configured). Some users find this
> >> confusing, because they would want to do further comparisons
> >> against the old state of the remote master, like:
> >>
> >>   $ git pull origin master
> >>   $ git log HEAD...origin/master
> >
> > I agree with the patch, but I would use a different reasoning. Your
> > example here is not even correct because the range in the second command
> > would be empty unless the merge conflicted.
> 
> Meh, I just read this again and saw that you actually had *three* dots.
> Serves me right for writing a reply on the phone.
> 
> So the quoted part is indeed correct.

Yes, it's correct, but it is a bit subtle. A better example would probably be:

  $ git status
  # On branch foo
  # Your branch is ahead of 'origin/master' by 2 commits.

  $ git pull origin master
  [pull 10 new commits]

  $ git status
  # On branch foo
  # Your branch is ahead of 'origin/master' by 13 commits.

That is technically true, but only because origin/master is now out of date. The more interesting number is 3: the two commits we had already, plus the new merge commit.

And of course there are infinite variations where you pull on one branch, and then switch branches to compare on another. But they all boil down to having an out-of-date view of origin/master that does not reflect the most recent pull.

-Peff