Re: git fetch documentation problem or bug

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> 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.