As some might know, I use the traditional non-separate-remotes layout in
many of my working trees. I am old fashioned.
I just tried to update one of them with "git pull --ff-only", and after
seeing that the fetch phase failed with non-ff on 'next', ran
$ git fetch origin +next
which happily copied the tip of updated next to FETCH_HEAD and nowhere
else. Of course, a colon-less refspec means do not store it anywhere,
i.e. "<colon-less-refspec>" === "<colon-less refspec>:", so prefixing it
with '+' to force would logically be a no-op. But it nevertheless was
somewhat surprising and irritating.
This is one of the many things that is so minor that it probably is not
worth risking backward compatibility issues to change, but something that
we would design differently if we were starting from scratch. Maybe in Git
2.0.
The question however is what should it do. I can see three possibilities:
(1) Forcing to fetch into FETCH_HEAD does not make any sense, so instead
of silently ignoring the '+' prefix, error it out and do not fetch
anything. This is easy to explain and logically makes more sense than
the current behaviour.
(2) Do notice '+' and understand that it is a request to force fetch into
some ref locally, and from the lack of colon and RHS, assume that the
user wants Git to infer the RHS using the configured refspec (in my
case, "refs/heads/next:refs/heads/next" is one of the configured
fetch refspec; "refs/heads/*:refs/remotes/origin/*" would be the one
that would match in the separate-remotes layout). In other words,
treat it as if the user typed "+refs/heads/next:refs/heads/next" (or
"+refs/heads/next:refs/remotes/origin/next" in the separate-remote
layout) from the command line.
(3) Do notice '+' is applied to 'next' but otherwise ignore the fact that
it is a command line pathspec, which would cause us to ignore
configured refspecs. In other words, fetch normally as if there were
no refspec on the command line, but when updating refs/heads/next (or
refs/remotes/origin/next in the separate-remotes layout), allow non
fast-forward updates.
The latter two are hard to explain and more error prone. I tend to think
both would be a mistake. If "+next" from the command line is modified to
update our remote tracking branch using the configured refspec, "next"
without '+' prefix also should. Otherwise the behaviour becomes too
inconsistent, but it is often convenient to fetch one-off even from a
configured remote using "git fetch origin next" into FETCH_HEAD without
updating our remote tracking branches, and change along the lines of
either (2) or (3) will forbid such a workflow.
Additionally (3) has very little advantage over "git fetch --force". If
'next' and 'master' both do not fast-forward, and the configured fetch
refspecs require both to fast-forward, "git fetch --force" would update
both, and "git fetch +next" with interpretation (3) would error out by
noticing that 'master' does not fast-forward. But anybody who is doing
"git fetch +next" already knows that 'next' does not fast-forward, and
that is because he has tried regular "git fetch" and saw both 'next' and
'master' fail back then, so he either wants to update only 'next', in
which case interpretation in (3) would not be helpful, or wants to update
both, in which case --force would be a better choice and exists already.
Perhaps we can/want to implement (1)?
--
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