Junio C Hamano <gitster@xxxxxxxxx> writes:
> In other words, you can do this from the command line if you want
> to do the update.
>
> $ git fetch origin master:refs/remotes/origin/master
Now having said all that, we should probably revisit this and
possibly other issues and for the ones we can reach concensus, start
coding after 1.8.0 final.
A good place to start may be $gmane/167149, where I listed (among
other things that turned out to be undesirable, which are omitted in
this copy):
* "git branch --set-upstream <name>" should not be about setting the
upstream of <name> to the current branch.
This has happened during 1.8.0 cycle [CMN].
* "git push" default semantics will be "upstream" (renamed from
"tracking"), not "matching".
1.8.0 has the first step toward this [MM].
* "git merge" without "what to merge" default to @{upstream}
This is not acceptable for the default, but the users can ask for
it with merge.defaultToUpstream since 1.7.5 era [JC]
* Unify pathspec semantics
This has happened and commands that used to take only path prefix
style pathspecs now take globs as well [ND]
* "git fetch $from $branch..." to update tracking branches
This is the topic in this thread.
I personally do not think the downside of breaking backward
compatibility is too bad. If we do this only when we already are
configured to keep remote tracking branch for branch $branch from
remote $from (it has to be given as a nickname, not URL that happens
to have an entry in the configuration), then a promiscuous fetch
that grabs from a URL (or a nickname that is configured not to keep
tracking branches) will not change any behaviour, and when you want
to keep your remote tracking branch intact while doing one-shot
fetch for whatever reason, you can say "git fetch $from $branch:" to
explicitly decline copying.
--
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