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

Marc Branchaud [off-list ref] writes:

On 11-10-16 03:20 AM, Junio C Hamano wrote:

quoted

As some might know, I use the traditional non-separate-remotes layout in
many of my working trees. I am old fashioned.

Being hip and modern :) I use separate remote refspecs.  As I read your post,
I kept thinking that it makes no sense for fetch to ever update local refs
and that you're a victim of your stodgy old ways.

Imagine a scenario where I run the same "git fetch origin +next" in a
repository with separate remotes layout, expecting that the remote
tracking branch refs/remotes/origin/next to be force updated. The fetched
value will be stored only in FETCH_HEAD, and I would feel exactly the same
minor irritation.

In other words, the issue does not have anything to do with the layout.
My mention of layout variants was only to clarify that the ref to be force
updated on the local side is determined by the suggested behaviours (2)
and (3) based on the fetch refspec (i.e. refs/heads/next in the
traditional layout, refs/remotes/origin/next in the separate remotes
layout).

This is a tangent but we have seen in the past some new people wonder why
their configured remote tracking refs are not updated when they do

	$ git fetch origin next

This is a variant without '+', and in such a case, in addition to list the
fetched tip in FETCH_HEAD, it might be more natural for the user to expect
that the usual remote tracking branch update to happen.  And I suspect
that the suggested semantics (2) might better match what the users expect
in general.

That is, when fetching from a remote that has configured fetch refspecs,
colon-less refspecs are given from the command line, are first matched
against the configured fetch refspecs for the remote, and used to update
the remote tracking branches. IOW, with the separate remote layout fetch
refspec, the above command line is re-written to

	$ git fetch origin refs/heads/next:refs/remotes/origin/next

and leaves the fetched tip of 'next' in FETCH_HEAD and updates the remote
tracking branch; nothing else is fetched.


And if we apply the '+' prefix in this context, as the natural
consequence, my original example would be rewritten to:

	$ git fetch origin +refs/heads/next:refs/remotes/origin/next

in a repository with the separate remote layout fetch refspec, and in a
repository with the non-separate remote layout, it would be rewritten to:

	$ git fetch origin +refs/heads/next:refs/heads/next

Historically, we never used configured fetch refspecs when refspecs are
given on the command line, so such a change definitely breaks backward
compatibility, but possibly in a good way, and might deserve consideration
for Git 2.0.