Re: What should "git fetch origin +next" should do?

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Oct 17, 2011, 22:02 UTC
Message-ID: <4E9CA5E2.2020701@xiplink.com>
In-Reply-To: <7vipnnmppx.fsf@alter.siamese.dyndns.org>

On 11-10-17 02:34 PM, Junio C Hamano wrote:

Show 12 quoted lines

> Jeff King <peff@peff.net> writes:
> 
>> I think the exact same confusion exists. I told git to update 'next'
>> from origin, but it didn't touch refs/remotes/origin/next.
> 
> Except that you didn't tell git to *update* the remote tracking branch for
> 'next'; you merely told it to fetch 'next' at the remote.
> 
>> ...  But I suspect that is not how many git users think of it.
> 
> I am inclined to agree that it might be the case; see my other message in
> this thread.

Indeed.  Apologies for missing that subtlety.

So now I think option (2) is the best choice. To support one-off fetches, teach fetch to accept "foo:" refspecs as "fetch ref foo from the remote and only update FETCH_HEAD" -- maybe allow "foo:FETCH_HEAD" too, for folks who like to be explicit and can't remember the shorthand syntax.

The rest of this post explains my reasoning, which I think pretty much just rehashes what Junio said more efficiently in his initial message.

Overall I'd expect "git fetch origin next" to be a subset of "git fetch
origin".  That is, since the default fetch refspec is
	+refs/heads/*:refs/remotes/origin/*
normally "git fetch origin" gets all of origin's updated refs (ff or not) and
puts them under the local remotes/origin/ space.  So I would expect "git
fetch origin next" to only fetch the "next" ref from origin and update the
local remotes/origin/next ref.

Given the default fetch refspec, I'd expect "git fetch origin +next" to do the exact same thing. The + on the command line is basically redundant.

But removing the + from the fetch refspec changes things. Now I'd expect plain "git fetch origin" to fail if there are any non-ff updates, and "git fetch origin next" should also fail if origin's next ref is non-ff. But "git fetch origin +next" would succeed.

In all cases if the command-line refspec has no RHS then git should try to figure out which local ref to update from the config, and it should die if it can't figure out a local ref to create or update. (As I said above, maybe allow "git fetch origin foo:" to let the user put the tip of origin's foo ref into FETCH_HEAD.)

All this gets a bit more complicated if the user has currently checked out the a ref that should be updated (regardless of the presence of a LHS +). But really only old-style git gurus should run in to that problem.

M.