Re: git fetch documentation problem or bug

Junio C Hamano [off-list ref] 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.

On Tue, Oct 9, 2012 at 6:33 AM, Junio C Hamano [off-list ref] wrote:

 * Unify pathspec semantics

   This has happened and commands that used to take only path prefix
   style pathspecs now take globs as well [ND]

I've been thinking about it lately and will probably restart soon with
a different approach. Still need to think about git-rm and git-mv as
they also accept directories (i.e. not exactly pathspec by
definition).
-- 
Duy

On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

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.

 * "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.

How are we supposed to remember those are different?

"git fetch $from $branch..."
VS
"git fetch $from $branch:"

I strongly prefer EXPLICITLY setting tracking than expecting some
extreme syntactic nuance to quietly do it for me now and confuse the
heck out of me later.

-- 
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59