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

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