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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 17, 2011, 17:09 UTC
Message-ID: <7v8vojo88p.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E9C3D27.3060504@xiplink.com>

Marc Branchaud <marcnarc@xiplink.com> writes:

Show 7 quoted lines

> On 11-10-16 03:20 AM, Junio C Hamano wrote:
>> 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.