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

[Marc Branchaud <marcnarc@xiplink.com>]

On 11-10-17 02:34 PM, Junio C Hamano wrote:
> 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.