"git pull REMOTE" question

"git pull REMOTE" question

[Miles Bader]

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.

>From my experimentation, it seems that this is because the local
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.
   $


-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: "git pull REMOTE" question

[Junio C Hamano]

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

> Is there a way to set things up so that "git pull REMOTE"
> automatically merges fetched branches when doing a non-default pull?

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

Re: "git pull REMOTE" question

[Miles Bader]

Junio C Hamano <gitster@pobox.com> writes:
>> Is there a way to set things up so that "git pull REMOTE"
>> automatically merges fetched branches when doing a non-default pull?
>
> The branch to be merged currently is determined per branch.
> You can just say "git pull usb master".

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

-- 
Do not taunt Happy Fun Ball.

Re: "git pull REMOTE" question

[Junio C Hamano]

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

> This apparent association of each local branch with a single remote
> seems slightly odd to me

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.

Re: "git pull REMOTE" question

[Jon Loeliger]

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

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

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

Re: "git pull REMOTE" question

[Junio C Hamano]

Jon Loeliger <jdl@freescale.com> writes:

> On Wed, 2007-08-22 at 00:11, Junio C Hamano wrote:
> ...
>>  ;; 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.
>
> 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

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.