"git pull REMOTE" question

Hi,

I have a .git/config file in my tree that looks like:

   [remote "origin"]
           url = ssh://HOST.org/home/miles/git/PROJECT.git
           fetch = +refs/heads/*:refs/remotes/origin/*
   [remote "usb"]
           url = /media/usb/git/PROJECT.git
           fetch = +refs/heads/*:refs/remotes/usb/*
   [branch "master"]
           remote = origin
           merge = refs/heads/master

and I'm normally using branch "master".

"git pull" or "git push", without arguments, do exactly the right thing for interacting with the "origin" remote.

When I want to push to "usb" (a usb thumbdrive), "git push usb" also does I want, but "git pull usb" does not: the git-fetch phase of the git-pull correctly fetches all the proper objects from the usb repository, but the git-merge part of the git-pull fails with an error message like:

   Warning: No merge candidate found because value of config option
            "branch.master.merge" does not match any remote branch fetched.
   No changes.

[See end of this message for a more complete output of a the pull command.]

After doing the pull, I can manually do the merge I want using a command like "git merge remotes/usb/master", but it's kind of annoying to have to do this every time.

branch "master" can only ever be associated with one remote ("origin" in this case), and the "branch.master.merge" config _only_ applies to that remote.

Is there a way to set things up so that "git pull REMOTE" automatically merges fetched branches when doing a non-default pull? If not, wouldn't this be a good feature to add?

Thanks,

-Miles

Here's the complete output of the git-pull command:

   $ git pull usb
   remote: Generating pack...
   remote: Done counting 59 objects.
   remote: Result has 38 objects.
   remote: Deltifying 38 objects...
   remote:
   Unpacking 38 objects...
   remote: Total 38 (delta 21), reused 24 (delta 8)
     97% (37/38) done 100% (38/38) done
   * refs/remotes/usb/master: storing branch 'master' of /media/usb/git/PROJECT
     commit: 243e656
   * refs/remotes/usb/branch1: storing branch 'branch1' of
/media/usb/git/PROJECT
     commit: e08c6ac
   * refs/remotes/usb/branch2: storing branch 'branch2' of
/media/usb/git/PROJECT
     commit: 8ad20e8
   * refs/remotes/usb/branch3: storing branch 'branch3' of
/media/usb/git/PROJECT
     commit: e874f3d
   Warning: No merge candidate found because value of config option
            "branch.master.merge" does not match any remote branch fetched.
   No changes.
   $

"Miles Bader" <miles@gnu.org> writes:

The branch to be merged currently is determined per branch. You can just say "git pull usb master".

Junio C Hamano <gitster@pobox.com> writes:

Right, but what I'm asking is whether there is (or should be) a way to automatically supply the "master", so I can just type "git pull usb" and have it do the right thing -- as there obviously is for the "origin" remote for this branch.

This apparent association of each local branch with a single remote seems slightly odd to me -- isn't it quite common for people to pull from various different remotes into the same local branch (e.g. for someone merging from the repositories of various regular contributors)?

Thanks,

-Miles

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.

On Wed, 2007-08-22 at 00:11, Junio C Hamano wrote:

Wasn't there was a brief alternate notion to add a "for <remote>" clause and allowing something like this?:

    [branch "master"]
        merge = refs/heads/xprm for usb
        merge = refs/heads/stuff for otherremote

Thanks, jdl

Jon Loeliger <jdl@freescale.com> writes:

Yeah, I remember that one (I do not think nobody implemented it, though). Thanks for reminding.

So...

	[branch "master"]
        	remote = origin
                merge = refs/heads/xprm for usb
                merge = refs/heads/stuff for otherremote
                merge = refs/heads/master

and when you are on your "master", 

	$ git fetch
        $ git pull

goes to "origin" (because you did not even say the remote name).

	$ git fetch usb
        $ git pull usb

goes to "usb". And "git pull" from such a nicknamed remote looks up merge lines with "for nickname" to find the branch(es) to merge. If there is no merge line with "for nickname" for the remote (e.g. "git pull origin" in the above example does not have any), and if there is a merge line without "for nickname", then that line can be used (e.g. "git pull" which is exactly the same as "git pull origin" will use the 'master' branch from the remote).

I think that is much easier to understand and maintain for the end users than the [branch "master:usb"]. The latter is wrong to begin with -- it is not about branch anymore.