Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior

[Theodore Tso <tytso@mit.edu>]

Luben,

Let me see if I can understand what you are asking for without using
the term "branch spec", which I don't think has been adequately
defined yet in this thread.  (Where "the SCM industry has adopted"
isn't a definition.  :-)

Currently, today, if you type:

	git fetch <non-URL>

... it will look up "<non-URL>" in a single global namespace, which
(using only the new config scheme) is looked up in remote.<non-URL>
and remote.<non-URL>.{url,fetch} is used to control the operation of
git-fetch.

What you want to do is to change this to where:

	git fetch <non-URL>

...will now lookup "<non-URL>" in a namespace which is qualified by
the branch that you are in.  So you want to look up the information in
branches.<current-branch>.<non-URL>.{url,fetch} instead.

You haven't stated it explicitly, but I assume that if
branches.<current-branch>.<non-URL> doesn't exist, you're proposing
that the code fall back to looking in the old configuration parameter,
remote.<non-URL>, so that certain names that should be global can
continue to be global, and that people who want a single global
namespace can continue to have it?

Is that your proposal, stripped of the arguments of why you want it,
and of the somewhat confusing "parent" example (which is a bad one
given that your "git pull parent" example was the semantic equivalent
of "git pull")?

If it is, I'm a bit nervous since it's making the git-fetch command
modal, and modal UI's are confusing to users.  On the other hand, it's
a fundamental modality we have already (based on the question "which
branch am I"), and there are hacks that will allow you to put the
current branch into your command-line.  And as long as you are
proposing a lookup in branches.current.branch.<non-URL> first before
checking remotes.<non-URL> it seems mostly harmless to me.  I doubt
I'd ever use it, but maybe it would be helpful to some.

						- Ted