Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html