From: Thomas Rast <trast@inf.ethz.ch>
Date: Sun, 12 May 2013 09:15:16 GMT
Subject: Re: [PATCH 4/4] fetch: opportunistically update tracking refs
Message-ID: <871u9cftjv.fsf@linux-k42r.v.cablecom.net>
In-Reply-To: <20130511161652.GD3270@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> When we run a regular "git fetch" without arguments, we
> update the tracking refs according to the configured
> refspec. However, when we run "git fetch origin master" (or
> "git pull origin master"), we do not look at the configured
> refspecs at all, and just update FETCH_HEAD.
>
> 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.

I believe the more common confusion stems from the tracking displays in
git-checkout and others.  The issue there is that we *internally* treat
origin/masters as a kind of mirror, and the tracking displays all go
against user expectations once they have seen a newer state of origin's
master by explicit pull or fetch.

Michael also pointed out yesterday that short of

  git fetch origin master:refs/remotes/origin/master

there is no way to fetch only one branch.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch