Re: "git pull REMOTE" question

Miles Bader <miles.bader@necel.com> writes:

I share the feeling. I think pulling from more than one remote is the norm, and moreover, pulling from more than one branch of one remote (depending on which branch you are pulling into) is also common. I did not even want to have the "when we are on this branch we would pull from that branch of that remote" we currently have to begin with, but this is what the list wanted, so there you are.

I _think_ the right approach is:

	git pull remote_name

when the user does not tell git which branch he is interested in merging should be to say:

 1. Do we have an association of our current-branch and the
    remote name that defines which branch to merge?  If so, use
    it (we do not have this right now, except for the case where
    remote_name matches branch.$current_branch.remote);

 2. Do we have a map from (current-branch, remote_name) to the
    branch to be merged?  If so, use it (we do not have this
    right now).

 3. Is there the primary branch remote side defines (aka
    refs/remotes/remote_name/HEAD)?  If so, use it (we do not do
    this at all);

So, how about extending the syntax for [branch $current_branch] section of the config like this?

 ;; traditional -- when on "master", use '[remote "origin"] url'
 ;; and '[remote "origin"] fetch' to decide where to fetch from,
 ;; and merge their refs/heads/master to our branch.
 [branch "master"]
 	remote = origin
        merge = refs/heads/master

 ;; new -- when on "master', and the user says to pull from "usb"
 ;; without saying which branch to merge, use '[remote "usb"] url'
 ;; and '[remote "usb"] fetch' to decide where to fetch from,
 ;; and merge their refs/heads/xprm to our branch.
 [branch "master:usb"]
 	merge = refs/heads/xprm

The trick in the new syntax is that you cannot have a colon in refname, so there is no way for existing [branch $name] section to crash with the new style definition.