git pull and merging.

git pull and merging.

[Aneesh Kumar]

I have a git.git clone using --use-separate-remote. That means i have
the master branch created by default. Now i need to build git from the
pu branch too. So i created git branch pu remotes/origin/pu.


How how do i track the pu branch using git pull. What i mean is the
master local branch is tracked by default using git pull. Is there a
way to track the local pu branch too.

I looked at git-repo-config and branch.<name>. config variable usage
is confusing. After initial try i concluded that it is to replace
.git/remotes/origin not the requirement i had.

Re: git pull and merging.

[Junio C Hamano]

"Aneesh Kumar" <aneesh.kumar@gmail.com> writes:

> I have a git.git clone using --use-separate-remote. That means i have
> the master branch created by default. Now i need to build git from the
> pu branch too. So i created git branch pu remotes/origin/pu.
>
>
> How how do i track the pu branch using git pull. What i mean is the
> master local branch is tracked by default using git pull. Is there a
> way to track the local pu branch too.

        $ cat >.git/remotes/origin <<\EOF
        URL: ...kernel.org/pub/scm/git/git.git
        Pull: refs/heads/master:refs/remotes/origin/master
        Pull: refs/heads/next:refs/remotes/origin/next
        Pull: +refs/heads/pu:refs/remotes/origin/pu
        EOF

Then you would checkout 'pu' by having a matching local branch:

	$ git branch pu remotes/origin/pu
	$ git checkout pu ;# this is your refs/heads/pu
        $ make

Hacking on it can be done in this branch as usual.  When you are
interested in the latest 'pu' from me:

	$ git checkout pu ;# this is your refs/heads/pu
	$ git fetch ;# most of the time git pull would also be fine...

and then:

	$ git rebase remotes/origin/pu

The 'rebase' in the last step is because my 'pu' rewinds freely;
otherwise you would do "git merge remotes/origin/pu" instead.

Re: git pull and merging.

[Aneesh Kumar]

On 12/6/06, Junio C Hamano <junkio@cox.net> wrote:
> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
>
> > I have a git.git clone using --use-separate-remote. That means i have
> > the master branch created by default. Now i need to build git from the
> > pu branch too. So i created git branch pu remotes/origin/pu.
> >
> >
> > How how do i track the pu branch using git pull. What i mean is the
> > master local branch is tracked by default using git pull. Is there a
> > way to track the local pu branch too.
>
>         $ cat >.git/remotes/origin <<\EOF
>         URL: ...kernel.org/pub/scm/git/git.git
>         Pull: refs/heads/master:refs/remotes/origin/master
>         Pull: refs/heads/next:refs/remotes/origin/next
>         Pull: +refs/heads/pu:refs/remotes/origin/pu
>         EOF
>
> Then you would checkout 'pu' by having a matching local branch:
>
>         $ git branch pu remotes/origin/pu
>         $ git checkout pu ;# this is your refs/heads/pu
>         $ make
>
> Hacking on it can be done in this branch as usual.  When you are
> interested in the latest 'pu' from me:
>
>         $ git checkout pu ;# this is your refs/heads/pu
>         $ git fetch ;# most of the time git pull would also be fine...
>
> and then:
>
>         $ git rebase remotes/origin/pu
>
> The 'rebase' in the last step is because my 'pu' rewinds freely;
> otherwise you would do "git merge remotes/origin/pu" instead.
>


Okey what i was looking for was a .git/config that will imply as a
part of git pull origin that local

master is to track remotes/origin/master
pu  should track remotes/origin/pu.

I almost felt the branch.<name>.merge was for that.

What is this git-repo-config used for. I am trying to understand


branch.<name>.remote and branch.<name>.merge usage.

Re: git pull and merging.

[Johannes Schindelin]

Hi,

On Wed, 6 Dec 2006, Aneesh Kumar wrote:

> On 12/6/06, Junio C Hamano <junkio@cox.net> wrote:
> 
> >         $ cat >.git/remotes/origin <<\EOF
> >         URL: ...kernel.org/pub/scm/git/git.git
> >         Pull: refs/heads/master:refs/remotes/origin/master
> >         Pull: refs/heads/next:refs/remotes/origin/next
> >         Pull: +refs/heads/pu:refs/remotes/origin/pu
> >         EOF
> 
> Okey what i was looking for was a .git/config that will imply as a
> part of git pull origin that local
> 
> master is to track remotes/origin/master
> pu  should track remotes/origin/pu.

You can have the same effect as what Junio wrote with the config:

$ git repo-config remote.origin.url git://git.kernel.org/pub/scm/git/git.git
$ git repo-config remote.origin.fetch \
	refs/heads/master:refs/remotes/origin/master
$ git repo-config remote.origin.fetch \
	refs/heads/next:refs/remotes/origin/next ^$
$ git repo-config remote.origin.fetch \
	+refs/heads/pu:refs/remotes/origin/pu ^$

But if you clone with recent git, that will already be set up for you 
(well, except that the "+" is missing in front of the "pu" thing, which 
says that it is okay if that particular ref is not fast-forwarding).

> I almost felt the branch.<name>.merge was for that.

No. This tells git which _default_ branch to merge with. I.e.

$ git repo-config branch.master.remote origin
$ git repo-config branch.master.merge next

means that if your current branch is "master", a "git pull" _without_ 
parameters will default to the branch "next" of the remote "origin" you 
just set up like above.

Hth,
Dscho

Re: git pull and merging.

[Peter Baumann]

On 2006-12-06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> You can have the same effect as what Junio wrote with the config:
>
> $ git repo-config remote.origin.url git://git.kernel.org/pub/scm/git/git.git
> $ git repo-config remote.origin.fetch \
> 	refs/heads/master:refs/remotes/origin/master
> $ git repo-config remote.origin.fetch \
> 	refs/heads/next:refs/remotes/origin/next ^$
> $ git repo-config remote.origin.fetch \
> 	+refs/heads/pu:refs/remotes/origin/pu ^$
>

What's that ^$ for?

-Peter

Re: git pull and merging.

[Johannes Schindelin]

Hi,

On Wed, 6 Dec 2006, Peter Baumann wrote:

> On 2006-12-06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > You can have the same effect as what Junio wrote with the config:
> >
> > $ git repo-config remote.origin.url git://git.kernel.org/pub/scm/git/git.git
> > $ git repo-config remote.origin.fetch \
> > 	refs/heads/master:refs/remotes/origin/master
> > $ git repo-config remote.origin.fetch \
> > 	refs/heads/next:refs/remotes/origin/next ^$
> > $ git repo-config remote.origin.fetch \
> > 	+refs/heads/pu:refs/remotes/origin/pu ^$
> >
> 
> What's that ^$ for?

We misuse the "nice" ini format a little bit in git: we allow multiple 
values for certain keys, like "remote.origin.fetch".

The normal mode for repo-config is to replace the value for the given key. 
By appending a regular expression, you can limit the replacement to 
certain matching _values_. And since "^$" means empty string, it does not 
match any, ensuring an append instead of a replace.

Ciao,
Dscho

Re: git pull and merging.

[Peter Baumann]

On Wed, Dec 06, 2006 at 11:14:01AM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Wed, 6 Dec 2006, Peter Baumann wrote:
> 
> > On 2006-12-06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > You can have the same effect as what Junio wrote with the config:
> > >
> > > $ git repo-config remote.origin.url git://git.kernel.org/pub/scm/git/git.git
> > > $ git repo-config remote.origin.fetch \
> > > 	refs/heads/master:refs/remotes/origin/master
> > > $ git repo-config remote.origin.fetch \
> > > 	refs/heads/next:refs/remotes/origin/next ^$
> > > $ git repo-config remote.origin.fetch \
> > > 	+refs/heads/pu:refs/remotes/origin/pu ^$
> > >
> > 
> > What's that ^$ for?
> 
> We misuse the "nice" ini format a little bit in git: we allow multiple 
> values for certain keys, like "remote.origin.fetch".
> 
> The normal mode for repo-config is to replace the value for the given key. 
> By appending a regular expression, you can limit the replacement to 
> certain matching _values_. And since "^$" means empty string, it does not 
> match any, ensuring an append instead of a replace.
> 
> Ciao,
> Dscho
> 

Another new thing learned today!
Thanks for the info.

Re: git pull and merging.

[Aneesh Kumar]

On 12/6/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I almost felt the branch.<name>.merge was for that.
>
> No. This tells git which _default_ branch to merge with. I.e.
>
> $ git repo-config branch.master.remote origin
> $ git repo-config branch.master.merge next
>
> means that if your current branch is "master", a "git pull" _without_
> parameters will default to the branch "next" of the remote "origin" you
> just set up like above.

This doesn't work. So this is what i tried
test repository with master and devel branch
cloned it to test.devel

.git/config have

[branch "devel"]
        remote = origin
        merge = devel

Now IIUC this should be when i am in branch devel when i do a git pull
pull from origin remote and merge with the local branch devel  the
remote branch devel.

But git pull says already up to date.

Now i thought merge should be local reference. So i changed it to
merge = remotes/origin/devel.

That also didn't work.

Then i tried the name of the branch should be indicated as
"refs/heads/devel" . That also didn't work.

So i guess i am missing something.

Re: git pull and merging.

[Jakub Narebski]

Aneesh Kumar wrote:

> [branch "devel"]
>         remote = origin
>         merge = devel

Does

  [branch "refs/heads/devel"]
        remote = origin
        merge = refs/remotes/origin/devel

works?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Fwd: git pull and merging.

[Aneesh Kumar]

After printing some debug echo i got this one which seems to be working for me

[branch "devel"]
        remote = origin

Re: git pull and merging.

[Josef Weidendorfer]

On Wednesday 06 December 2006 11:05, Aneesh Kumar wrote:
> [branch "devel"]
>         remote = origin
>         merge = devel
> 
> [....]
> Now i thought merge should be local reference. So i changed it to
> merge = remotes/origin/devel.
> 
> That also didn't work.
> 
> Then i tried the name of the branch should be indicated as
> "refs/heads/devel" . That also didn't work.
> 
> So i guess i am missing something.

See man page of git-repo-config:

 branch.<name>.merge
  When in branch <name>, it tells git fetch the default
  remote branch to be merged.

I assume that the "devel" branch on the remote repo you cloned from
is also "devel", more exactly "refs/heads/devel".

Now, instead of "git pull", git should default to

	git pull origin refs/heads/devel:refs/remotes/origin/devel

ie. it should update the local tracking branch "refs/remotes/origin/devel"
with the remote branch "refs/heads/devel".
The tracking branch "refs/remotes/origin/devel" will be merged with current
branch afterwards.

Now looking at the documentation for branch.<name>.merge, it talks
about the remote branch, which is "refs/heads/devel" in your case, ie.
the first part of the refspec of the full "git pull" command above.

So, as you already posted (without explanation, therefore this mail),
the config should be

 [branch "devel"]
         remote = origin
         merge = refs/heads/devel

However, "devel" alone should work here, as it can be matched with remote
"refs/heads/devel". Seems to be a bug, as branch.<name>.merge seems to only
being compared with the full canonical name in the implementation.

Josef

Re: git pull and merging.

[Aneesh Kumar K.V]

Josef Weidendorfer wrote:
> On Wednesday 06 December 2006 11:05, Aneesh Kumar wrote:
>> [branch "devel"]
>>         remote = origin
>>         merge = devel
>>
>> [....]
>> Now i thought merge should be local reference. So i changed it to
>> merge = remotes/origin/devel.
>>
>> That also didn't work.
>>
>> Then i tried the name of the branch should be indicated as
>> "refs/heads/devel" . That also didn't work.
>>
>> So i guess i am missing something.
> 
> See man page of git-repo-config:
> 
>  branch.<name>.merge
>   When in branch <name>, it tells git fetch the default
>   remote branch to be merged.
> 
> I assume that the "devel" branch on the remote repo you cloned from
> is also "devel", more exactly "refs/heads/devel".
> 
> Now, instead of "git pull", git should default to
> 
> 	git pull origin refs/heads/devel:refs/remotes/origin/devel



this means the remote reference is refs/heads/devel and local tracking branch for that is refs/remotes/origin/devel.




> 
> ie. it should update the local tracking branch "refs/remotes/origin/devel"
> with the remote branch "refs/heads/devel".
> The tracking branch "refs/remotes/origin/devel" will be merged with current
> branch afterwards.
> 


That will be merged is the tricky part. 



> Now looking at the documentation for branch.<name>.merge, it talks
> about the remote branch, which is "refs/heads/devel" in your case, ie.
> the first part of the refspec of the full "git pull" command above.
> 

This is most confusing part. What merge indicate is not about refs/heads/devel
should track refs/remotes/origin/devel. That is specfied in the remote config option.

What merge indicate is that when in a local branch ( not the tracking one under remotes/origin)
which branch from remote need to be used to merge to the local branch.




> So, as you already posted (without explanation, therefore this mail),
> the config should be
> 
>  [branch "devel"]
>          remote = origin
>          merge = refs/heads/devel
> 
> However, "devel" alone should work here, as it can be matched with remote
> "refs/heads/devel". Seems to be a bug, as branch.<name>.merge seems to only
> being compared with the full canonical name in the implementation.


I guess we need to have a standard way of saying the branches. 

May be we want to document it in repo-config.

local branch on which changes can be made <branch-name>
local tracking branch refs/remotes/<remote-name>/<branch-name>
remote branch refs/heads/<branch-name>

Re: git pull and merging.

[Josef Weidendorfer]

On Thursday 07 December 2006 07:46, Aneesh Kumar K.V wrote:
> Josef Weidendorfer wrote:

> > Now, instead of "git pull", git should default to
> > 
> > 	git pull origin refs/heads/devel:refs/remotes/origin/devel
> 
> 
> 
> this means the remote reference is refs/heads/devel and local tracking
> branch for that is refs/remotes/origin/devel. 

Yes.

> > ie. it should update the local tracking branch "refs/remotes/origin/devel"
> > with the remote branch "refs/heads/devel".
> > The tracking branch "refs/remotes/origin/devel" will be merged with current
> > branch afterwards.
> > 
> 
> 
> That will be merged is the tricky part.

No. The merging part actually is the easiest, because everything about
what to merge with what is already decided in "git pull" 's fetch phase:

* git fetch leaves the branches fetched _and_ what to merge of them
in .git/FETCH_HEAD. Example for "git pull" it git.git's master(shorted):

de51fa... branch 'master' of git://.../git/git
49ed2b... not-for-merge   branch 'maint' of git://.../git/git
b772ef... not-for-merge   branch 'next' of git://.../git/git

Which means: Already in the fetch phase, we look up branch.*.merge to
decide what to write into this file.

* the merge phase just looks up .git/FETCH_HEAD and merges all branches into
the current branch which are _not_ marked as "not-for-merge". There
is nothing tricky here: We did the 1st phase of pull in the same
"current" branch, so there really is no need to check any branch.*.merge
value again.

> > Now looking at the documentation for branch.<name>.merge, it talks
> > about the remote branch, which is "refs/heads/devel" in your case, ie.
> > the first part of the refspec of the full "git pull" command above.
> > 
> 
> This is most confusing part. What merge indicate is not about refs/heads/devel
> should track refs/remotes/origin/devel. That is specfied in the remote config option.

Yes. But the value of branch.*.merge, which is the _remote_ side of such a refspec
tracking specification given in remote.*.fetch's, will be checked against all
remote parts of refspecs fetched in the 1st phase of "git pull". And it is already
decided in the fetch phase what to merge.

Now looking at it, I think this semantic really is screwed and utterly confusing.
Why decides branch.*.merge about actions done in fetch (I think even if you did
"git fetch" alone)? OK, actually, that is an implementation detail and not
really important.

More important: Because "branch.*.merge" specifies a _remote_ branch,
the user has to understand that this info is already used in the fetch.
The intuitive mental model of a user about how it works IMHO is that
"branch.*.merge" is checked in the merge phase (as the name of the option suggests).
But this way, how could the merge phase know about any remote branch at all,
which does not need to be touched at all in the merge phase?

IMHO we should somehow change the semantic of branch.*.merge to specify the _local_
refspec part, as this is the branch which actually gets merged.
This is the only way that a user could grasp the meaning of it.
Perhaps introduce "branch.*.defaultmerge", and obsoleting "branch.*.merge"?

> I guess we need to have a standard way of saying the branches. 
> 
> May be we want to document it in repo-config.
> 
> local branch on which changes can be made <branch-name>
> local tracking branch refs/remotes/<remote-name>/<branch-name>

This is not forced, but can be changed by configuration.

> remote branch refs/heads/<branch-name>

?

Re: git pull and merging.

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> More important: Because "branch.*.merge" specifies a _remote_ branch,
> the user has to understand that this info is already used in the fetch.
> The intuitive mental model of a user about how it works IMHO is that
> "branch.*.merge" is checked in the merge phase (as the name of the option suggests).
> But this way, how could the merge phase know about any remote branch at all,
> which does not need to be touched at all in the merge phase?

I accepted the "branch.*.merge" patch long time ago but I did
not see the point of moving things into config back then, so I
did not look at the design issue deeply enough to notice that
this can be a source of confusion (in other words, "I wouldn't
use it myself, but I've seen some people on the list wanting to
have it, and the submitter must have thought about what are
needed a lot more than myself" did not go so well).

Once you place something like "branch.*.merge" in configuration
file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
are talking about other repositories you regularly interact
with, so it might be probably Ok to require the user to use a
tracking branch if he wants the convenience of "branch.*.merge",
and make its value name the local tracking branch instead of the
remote branch.

But that means I would never be able to benefit from the
convenience of "branch.*.merge"; I pull from gitk repository to
get updates, but I do not have (and I do not see the point to
have) a remote tracking branch to track it.  If you want to
cater to people who fetch and merge without using tracking
branches, the remote branch name is the only sane thing you can
use for the value of "branch.*.merge".

Re: git pull and merging.

[Josef Weidendorfer]

On Thursday 07 December 2006 20:06, you wrote:
> Once you place something like "branch.*.merge" in configuration
> file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
> are talking about other repositories you regularly interact
> with, so it might be probably Ok to require the user to use a
> tracking branch if he wants the convenience of "branch.*.merge",
> and make its value name the local tracking branch instead of the
> remote branch.
> 
> But that means I would never be able to benefit from the
> convenience of "branch.*.merge";

Hmm... that's true; actually, I did not thought about people
which do not want to have any tracking branches (again!). So

[remote "repo"]
  url = ...
  fetch = branch1
  fetch = branch2

[branch "mybranch1"]
  remote = repo
  merge = branch1

actually looks fine, and is the only possible way.
But still, this does not work. You have to specify

  merge = refs/heads/branch1

That's confusing (perhaps I can come up with a patch
to allow "branch1" alone).

So probably the best way is to write some more detailed
explanation into the docu ...

Re: git pull and merging.

[Santi Béjar]

On 12/7/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Thursday 07 December 2006 20:06, you wrote:
> > Once you place something like "branch.*.merge" in configuration
> > file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
> > are talking about other repositories you regularly interact
> > with, so it might be probably Ok to require the user to use a
> > tracking branch if he wants the convenience of "branch.*.merge",
> > and make its value name the local tracking branch instead of the
> > remote branch.
> >
> > But that means I would never be able to benefit from the
> > convenience of "branch.*.merge";
>
> Hmm... that's true; actually, I did not thought about people
> which do not want to have any tracking branches (again!). So
>
> [remote "repo"]
>   url = ...
>   fetch = branch1
>   fetch = branch2
>
> [branch "mybranch1"]
>   remote = repo
>   merge = branch1
>
> actually looks fine, and is the only possible way.
> But still, this does not work.

It works for me.

> You have to specify
>
>   merge = refs/heads/branch1

It does not.

The merge line must match exactly the remote part of the refspec.

>
> That's confusing (perhaps I can come up with a patch
> to allow "branch1" alone).
>
> So probably the best way is to write some more detailed
> explanation into the docu ...

Perhaps that the branch.<name>.remote and branch.<name>.merge have the
equivalent meaning as the parameters of git-pull?

>
> Josef
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git pull and merging.

[Josef Weidendorfer]

On Friday 08 December 2006 02:56, Santi Béjar wrote:
> > [remote "repo"]
> >   url = ...
> >   fetch = branch1
> >   fetch = branch2
> >
> > [branch "mybranch1"]
> >   remote = repo
> >   merge = branch1
> >
> > actually looks fine, and is the only possible way.
> > But still, this does not work.
> 
> It works for me.
> 
> > You have to specify
> >
> >   merge = refs/heads/branch1
> 
> It does not.
> 
> The merge line must match exactly the remote part of the refspec.

Yes, you are right; I just looked it up in git-parse-remote.
Sorry about any confusion.

> 
> >
> > That's confusing (perhaps I can come up with a patch
> > to allow "branch1" alone).
> >
> > So probably the best way is to write some more detailed
> > explanation into the docu ...
> 
> Perhaps that the branch.<name>.remote and branch.<name>.merge have the
> equivalent meaning as the parameters of git-pull?

We want to fetch multiple refs from one remote in a row. So what
are you proposing? That branch.<name>.merge has to exactly
specify one remote? I do not think this is needed.

Actually, I am really for a new branch.<name>.localmerge option,
and keeping branch.<name>.merge (but not advertising it).

[PATCH] Add branch.*.localmerge and documentation update

[Josef Weidendorfer]

Clarify the meaning of branch.*.merge option and add a similar
branch.*.localmerge option, which can be used to specify a local
tracking branch to be merged by default.

Previously, if branch.*.merge was specified but did not match any
ref, the message "No changes." was not really helpful regarding
the misconfiguration. This now gives a warning.

The value of branch.*.merge can be a list to get an octopus
merge. I chose the same way for branch.*.localmerge, and if
you specify both options, the octopus merge will have even
more parents ;-)

Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---

This implements to branch.*.localmerge option as counterpart
to branch.*.merge as discussed.

To get the "No default merge when any branch.*.(local)merge is given,
but not in current branch" feature, what is the way to check this,
as git-repo-config can not match with regexps against config keys?

Josef

 Documentation/config.txt |   23 +++++++++++++++++++++--
 git-parse-remote.sh      |   40 +++++++++++++++++++++++++++++++---------
 2 files changed, 52 insertions(+), 11 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9090762..6e19130 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -125,10 +125,29 @@ apply.whitespace::
 
 branch.<name>.remote::
 	When in branch <name>, it tells `git fetch` which remote to fetch.
+	If this option is not given, `git fetch` defaults to "origin".
 
 branch.<name>.merge::
-	When in branch <name>, it tells `git fetch` the default remote branch
-	to be merged.
+	When in branch <name>, it tells `git fetch` the default refspec to
+	be marked for merging in FETCH_HEAD. The value has to exactly
+	match a remote part of the refspecs which are fetched from the remote
+	repository given by "branch.<name>.remote".
+	The merge information is used by `git pull` (which first calls
+	`git fetch`) for the default merge action.
+	Without this or a "branch.<name>.localmerge" option, `git pull` defaults to
+	the first refspec fetched.
+	Specify multiple values to get an octopus merge.
+
+branch.<name>.localmerge::
+	When in branch <name>, it tells `git fetch` the default refspec to
+	be marked for merging in FETCH_HEAD. The value has to exactly
+	match a local part (i.e. the local tracking branch) of the refspecs
+	which are fetched from the remote repository given by "branch.<name>.remote".
+	The merge information is used by `git pull` (which first calls
+	`git fetch`) for the default merge action.
+	Without this or a "branch.<name>.merge" option, `git pull` defaults to the
+	first refspec fetched.
+	Specify multiple values to get an octopus merge.
 
 pager.color::
 	A boolean to enable/disable colored output when the pager is in
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index da064a5..08ab272 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -133,7 +133,9 @@ canon_refs_list_for_fetch () {
 	# leave the branches in branch.${curr_branch}.merge alone,
 	# or the first one otherwise; add prefix . to the rest
 	# to prevent the secondary branches to be merged by default.
-	merge_branches=
+	merge_remotebranches=
+	merge_localbranches=
+	found_mergerefs=
 	if test "$1" = "-d"
 	then
 		shift ; remote="$1" ; shift
@@ -141,8 +143,10 @@ canon_refs_list_for_fetch () {
 		then
 			curr_branch=$(git-symbolic-ref HEAD | \
 			    sed -e 's|^refs/heads/||')
-			merge_branches=$(git-repo-config \
+			merge_remotebranches=$(git-repo-config \
 			    --get-all "branch.${curr_branch}.merge")
+			merge_localbranches=$(git-repo-config \
+			    --get-all "branch.${curr_branch}.localmerge")
 		fi
 		set x $(expand_refs_wildcard "$@")
 		shift
@@ -160,17 +164,31 @@ canon_refs_list_for_fetch () {
 		remote=$(expr "z$ref" : 'z\([^:]*\):')
 		local=$(expr "z$ref" : 'z[^:]*:\(.*\)')
 		dot_prefix=.
-		if test -z "$merge_branches"
+		if test ! -z "$merge_remotebranches"
 		then
-			merge_branches=$remote
-			dot_prefix=
-		else
-			for merge_branch in $merge_branches
+			for merge_branch in $merge_remotebranches
 			do
-			    [ "$remote" = "$merge_branch" ] &&
-			    dot_prefix= && break
+				[ "$remote" = "$merge_branch" ] &&
+				dot_prefix= && break
 			done
 		fi
+		if test ! -z "$merge_localbranches"
+		then
+			for merge_branch in $merge_localbranches
+			do
+				[ "$local" = "$merge_branch" ] &&
+				dot_prefix= && break
+			done
+		fi
+		if test -z "$merge_remotebranches" -a -z "$merge_localbranches"
+		then
+			merge_remotebranches=$remote
+			dot_prefix=
+		fi
+		if test -z $dot_prefix
+		then
+			found_mergeref=true
+		fi
 		case "$remote" in
 		'') remote=HEAD ;;
 		refs/heads/* | refs/tags/* | refs/remotes/*) ;;
@@ -191,6 +209,10 @@ canon_refs_list_for_fetch () {
 		fi
 		echo "${dot_prefix}${force}${remote}:${local}"
 	done
+	if test -z $found_mergeref
+	then
+		echo >&2 "Warning: No merge candidate because of no match with branch.*.merge or branch.*.localmerge"
+	fi
 }
 
 # Returns list of src: (no store), or src:dst (store)
-- 

Re: [PATCH] Add branch.*.localmerge and documentation update

[Santi Béjar]

On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> Clarify the meaning of branch.*.merge option and add a similar
> branch.*.localmerge option, which can be used to specify a local
> tracking branch to be merged by default.
>
> Previously, if branch.*.merge was specified but did not match any
> ref, the message "No changes." was not really helpful regarding
> the misconfiguration. This now gives a warning.
>
> The value of branch.*.merge can be a list to get an octopus
> merge. I chose the same way for branch.*.localmerge, and if
> you specify both options, the octopus merge will have even
> more parents ;-)
>
> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>

Ack for the documentation part. But the localmerge part is almost
equivalent to my patch to allow the branch.<name>.remote equal to ".".

Re: [PATCH] Add branch.*.localmerge and documentation update

[Junio C Hamano]

"Santi Béjar" <sbejar@gmail.com> writes:

> On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
>> Clarify the meaning of branch.*.merge option and add a similar
>> branch.*.localmerge option, which can be used to specify a local
>> tracking branch to be merged by default.
>>
>> Previously, if branch.*.merge was specified but did not match any
>> ref, the message "No changes." was not really helpful regarding
>> the misconfiguration. This now gives a warning.
>>
>> The value of branch.*.merge can be a list to get an octopus
>> merge. I chose the same way for branch.*.localmerge, and if
>> you specify both options, the octopus merge will have even
>> more parents ;-)
>>
>> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
>
> Ack for the documentation part. But the localmerge part is almost
> equivalent to my patch to allow the branch.<name>.remote equal to ".".

I am not so sure about the "localmerge" stuff anymore.

What convenience would it buy us (including but not limited to
new people), and if there is any, would that outweigh the
potential confusion factor to have two different configuration
variables that do exactly the same thing whose sole difference
is which side of the fetched branch namespace it uses to specify
the merge source?

Re: [PATCH] Add branch.*.localmerge and documentation update

[Jakub Narebski]

<opublikowany i wysłany>

Junio C Hamano wrote:

> "Santi Béjar" <sbejar@gmail.com> writes:
> 
>> On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
>>> Clarify the meaning of branch.*.merge option and add a similar
>>> branch.*.localmerge option, which can be used to specify a local
>>> tracking branch to be merged by default.
>>>
>>> Previously, if branch.*.merge was specified but did not match any
>>> ref, the message "No changes." was not really helpful regarding
>>> the misconfiguration. This now gives a warning.
[...]
>>
>> Ack for the documentation part. But the localmerge part is almost
>> equivalent to my patch to allow the branch.<name>.remote equal to ".".
> 
> I am not so sure about the "localmerge" stuff anymore.
> 
> What convenience would it buy us (including but not limited to
> new people), and if there is any, would that outweigh the
> potential confusion factor to have two different configuration
> variables that do exactly the same thing whose sole difference
> is which side of the fetched branch namespace it uses to specify
> the merge source?

What about my proposal to allow for full refspec, or :<localbranch>
to be specified? I.e. allow all the following forms:
  branch.<name>.merge = refs/heads/<remotebranch>
  branch.<name>.merge = refs/heads/<remotebranch>:refs/remotes/<remote>/<localbranch>
  branch.<name>.merge = :refs/remotes/<remote>/<localbranch>

By the way, if branch.*.remote is equal to ".", remote branch is
local branch.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] Add branch.*.localmerge and documentation update

[Josef Weidendorfer]

On Friday 08 December 2006 22:38, Junio C Hamano wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
> 
> > On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> >> Clarify the meaning of branch.*.merge option and add a similar
> >> branch.*.localmerge option, which can be used to specify a local
> >> tracking branch to be merged by default.
> 
> I am not so sure about the "localmerge" stuff anymore.
> 
> What convenience would it buy us (including but not limited to
> new people), and if there is any, would that outweigh the
> potential confusion factor to have two different configuration
> variables that do exactly the same thing whose sole difference
> is which side of the fetched branch namespace it uses to specify
> the merge source?

I just came up with a concrete patch.
I am not saying that this is the only true solution.

Actually, Jakubs one with allowing arbitrary refspecs is nice.
The only problem is that it is not consistent which refspec
shortcuts otherwise, or?

However, you should take the documentation part and the warning
when there is no match .

Re: [PATCH] Add branch.*.localmerge and documentation update

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Friday 08 December 2006 22:38, Junio C Hamano wrote:
>> "Santi Béjar" <sbejar@gmail.com> writes:
>> 
>> > On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
>> >> Clarify the meaning of branch.*.merge option and add a similar
>> >> branch.*.localmerge option, which can be used to specify a local
>> >> tracking branch to be merged by default.
>> 
>> I am not so sure about the "localmerge" stuff anymore.
>> 
>> What convenience would it buy us (including but not limited to
>> new people), and if there is any, would that outweigh the
>> potential confusion factor to have two different configuration
>> variables that do exactly the same thing whose sole difference
>> is which side of the fetched branch namespace it uses to specify
>> the merge source?
>
> I just came up with a concrete patch.
> I am not saying that this is the only true solution.

I admit that I do not use branch.*.merge and I do not know what
people find lacking in what Santi did in late September with
commit 5372806.  What problem are we trying to solve (not a
rhetorical question -- I am truly lost here)?  Is it only a
confusion between remote and local, or is there something that
cannot be expressed with the current scheme?

> Actually, Jakubs one with allowing arbitrary refspecs is nice.
> The only problem is that it is not consistent which refspec
> shortcuts otherwise, or?

Actually I had a quite opposite reaction about allowing src:dst
notation there.  Does it solve any real problem?  It is unclear
to me.  On the other hand, it gives a false impression that it
can be used instead of remote.*.fetch to copy the remote branch
into local tracking branch, and raises other questions such as
what should happen when you have both, i.e. src:dst is given to
both remote.*.fetch and branch.*.merge, and they do not agree.
Which means it only adds to the confusion.

So I do not think it is worth spending brain cycles talking
about that particular one; it does not even have a patch to 
implement it.

But you have a concrete patch, and if it is fixing a real
problem, then that is worth talking about.  I just do not know
if a problem exists, other than that people can get confused and
write local tracking branch name by mistake when it should be
remote branch name.

Re: [PATCH] Add branch.*.localmerge and documentation update

[Josef Weidendorfer]

On Friday 08 December 2006 23:34, Junio C Hamano wrote:
> >> What convenience would it buy us (including but not limited to
> >> new people), and if there is any, would that outweigh the
> >> potential confusion factor to have two different configuration
> >> variables that do exactly the same thing whose sole difference
> >> is which side of the fetched branch namespace it uses to specify
> >> the merge source?
> >
> > I just came up with a concrete patch.
> > I am not saying that this is the only true solution.
> 
> I admit that I do not use branch.*.merge and I do not know what
> people find lacking in what Santi did in late September with
> commit 5372806.  What problem are we trying to solve (not a
> rhetorical question -- I am truly lost here)?  Is it only a
> confusion between remote and local, or is there something that
> cannot be expressed with the current scheme?

More or less, yes.

When this thread started, I remembered being bitten exactly by
this issue. And I only understood my problem after looking and
trying to understand the code.
Therefore, it was quite easy to come up with this patch.

IMHO, a problem really is the people do not want to read documentation.
They see the branch.*.merge option in .git/config, and try to build
their own mental model how it works.

Perhaps the warning I added now would have been enough for me to see
my error; it points at the misconfigured option. For sure, I would
have looked up the manual for the meaning of this option after seeing
the warning.
But the previous documentation simply was way to short.

Should I send a "simplified" patch?

Re: [PATCH] Add branch.*.localmerge and documentation update

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> But the previous documentation simply was way to short.

Yes, your documentation updates seems to make it much clearer.

> Should I send a "simplified" patch?

Thanks, appreciated.

[PATCH] Add branch.*.merge warning and documentation update

[Josef Weidendorfer]

This patch clarifies the meaning of the branch.*.merge option.
Previously, if branch.*.merge was specified but did not match any
ref, the message "No changes." was not really helpful regarding
the misconfiguration. This patch adds a warning for this.

Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---

On Saturday 09 December 2006 00:41, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> > But the previous documentation simply was way to short.
> 
> Yes, your documentation updates seems to make it much clearer.
> 
> > Should I send a "simplified" patch?
> 
> Thanks, appreciated.

Done.

Josef

 Documentation/config.txt |   11 +++++++++--
 git-parse-remote.sh      |   11 +++++++++++
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9090762..21ec557 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -125,10 +125,17 @@ apply.whitespace::
 
 branch.<name>.remote::
 	When in branch <name>, it tells `git fetch` which remote to fetch.
+	If this option is not given, `git fetch` defaults to remote "origin".
 
 branch.<name>.merge::
-	When in branch <name>, it tells `git fetch` the default remote branch
-	to be merged.
+	When in branch <name>, it tells `git fetch` the default refspec to
+	be marked for merging in FETCH_HEAD. The value has exactly to match
+	a remote part of one of the refspecs which are fetched from the remote
+	given by "branch.<name>.remote".
+	The merge information is used by `git pull` (which at first calls
+	`git fetch`) to lookup the default branch for merging. Without
+	this option, `git pull` defaults to merge the first refspec fetched.
+	Specify multiple values to get an octopus merge.
 
 pager.color::
 	A boolean to enable/disable colored output when the pager is in
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index da064a5..d72f061 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -134,6 +134,8 @@ canon_refs_list_for_fetch () {
 	# or the first one otherwise; add prefix . to the rest
 	# to prevent the secondary branches to be merged by default.
 	merge_branches=
+	found_mergeref=
+	curr_branch=
 	if test "$1" = "-d"
 	then
 		shift ; remote="$1" ; shift
@@ -171,6 +173,10 @@ canon_refs_list_for_fetch () {
 			    dot_prefix= && break
 			done
 		fi
+		if test -z $dot_prefix
+		then
+			found_mergeref=true
+		fi
 		case "$remote" in
 		'') remote=HEAD ;;
 		refs/heads/* | refs/tags/* | refs/remotes/*) ;;
@@ -191,6 +197,11 @@ canon_refs_list_for_fetch () {
 		fi
 		echo "${dot_prefix}${force}${remote}:${local}"
 	done
+	if test -z "$found_mergeref" -a "$curr_branch"
+	then
+		echo >&2 "Warning: No merge candidate found because value of config option
+         \"branch.${curr_branch}.merge\" does not match any remote branch fetched."
+	fi
 }
 
 # Returns list of src: (no store), or src:dst (store)
-- 
1.4.4.2.g1d08-dirty

Re: [PATCH] Add branch.*.merge warning and documentation update

[Santi Béjar]

On 12/9/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> This patch clarifies the meaning of the branch.*.merge option.
> Previously, if branch.*.merge was specified but did not match any
> ref, the message "No changes." was not really helpful regarding
> the misconfiguration. This patch adds a warning for this.
>
> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>

Acked-by: Santi Béjar <sbejar@gmail.com>

And thanks for the patch.

Re: [PATCH] Add branch.*.localmerge and documentation update

[Josef Weidendorfer]

On Friday 08 December 2006 21:52, Santi Béjar wrote:
> On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > Clarify the meaning of branch.*.merge option and add a similar
> > branch.*.localmerge option, which can be used to specify a local
> > tracking branch to be merged by default.
> >
> > Previously, if branch.*.merge was specified but did not match any
> > ref, the message "No changes." was not really helpful regarding
> > the misconfiguration. This now gives a warning.
> >
> > The value of branch.*.merge can be a list to get an octopus
> > merge. I chose the same way for branch.*.localmerge, and if
> > you specify both options, the octopus merge will have even
> > more parents ;-)
> >
> > Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
> 
> Ack for the documentation part. But the localmerge part is almost
> equivalent to my patch to allow the branch.<name>.remote equal to ".".

Interesting. I did not have a look at your patch.
The support for the "branch.*.localmerge" option is one step to be
able to support a remote ".". So of course, it probably is similar.
I even would say that "." as remote now actually makes sense as
logical extension.

However, what would you change in the implementation part of my patch?

Re: [PATCH] Add branch.*.localmerge and documentation update

[Santi Béjar]

On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Friday 08 December 2006 21:52, Santi Béjar wrote:
> > On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > > Clarify the meaning of branch.*.merge option and add a similar
> > > branch.*.localmerge option, which can be used to specify a local
> > > tracking branch to be merged by default.
> > >
> > > Previously, if branch.*.merge was specified but did not match any
> > > ref, the message "No changes." was not really helpful regarding
> > > the misconfiguration. This now gives a warning.
> > >
> > > The value of branch.*.merge can be a list to get an octopus
> > > merge. I chose the same way for branch.*.localmerge, and if
> > > you specify both options, the octopus merge will have even
> > > more parents ;-)
> > >
> > > Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
> >
> > Ack for the documentation part. But the localmerge part is almost
> > equivalent to my patch to allow the branch.<name>.remote equal to ".".
>
> Interesting. I did not have a look at your patch.
> The support for the "branch.*.localmerge" option is one step to be
> able to support a remote ".". So of course, it probably is similar.
> I even would say that "." as remote now actually makes sense as
> logical extension.
>
> However, what would you change in the implementation part of my patch?

I would only take the documentation part (without the localmerge part)
and the test for the warning.

Re: git pull and merging.

[Santi Béjar]

On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Friday 08 December 2006 02:56, Santi Béjar wrote:
> > > [remote "repo"]
> > >   url = ...
> > >   fetch = branch1
> > >   fetch = branch2
> > >
> > > [branch "mybranch1"]
> > >   remote = repo
> > >   merge = branch1
> > >
> > > actually looks fine, and is the only possible way.
> > > But still, this does not work.
> >
> > It works for me.
> >
> > > You have to specify
> > >
> > >   merge = refs/heads/branch1
> >
> > It does not.
> >
> > The merge line must match exactly the remote part of the refspec.
>
> Yes, you are right; I just looked it up in git-parse-remote.
> Sorry about any confusion.
>
> >
> > >
> > > That's confusing (perhaps I can come up with a patch
> > > to allow "branch1" alone).
> > >
> > > So probably the best way is to write some more detailed
> > > explanation into the docu ...
> >
> > Perhaps that the branch.<name>.remote and branch.<name>.merge have the
> > equivalent meaning as the parameters of git-pull?
>
> We want to fetch multiple refs from one remote in a row. So what
> are you proposing? That branch.<name>.merge has to exactly
> specify one remote? I do not think this is needed.

I'm not proposing anything. What I wanted to say is that we could
document the ...remote and ...merge configs as the default parameters
of git-pull (this is how it is implemented already).

>
> Actually, I am really for a new branch.<name>.localmerge option,
> and keeping branch.<name>.merge (but not advertising it).

I do not see anything wrong with the current ...remote and ...merge
(see above), but I'm not against the ...localmerge config.

Re: git pull and merging.

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

>> But that means I would never be able to benefit from the
>> convenience of "branch.*.merge";
>
> Hmm... that's true; actually, I did not thought about people
> which do not want to have any tracking branches (again!). So
>
> [remote "repo"]
>   url = ...
>   fetch = branch1
>   fetch = branch2
>
> [branch "mybranch1"]
>   remote = repo
>   merge = branch1
>
> actually looks fine, and is the only possible way.

Yeah, when you lay it out that way, it absolutely makes sense to
have "branch1" which is the name of the remote branch, not the
local counterpart that tracks it, as the value of the "merge"
configuration.

> But still, this does not work. You have to specify
>
>   merge = refs/heads/branch1
>
> That's confusing (perhaps I can come up with a patch
> to allow "branch1" alone).

I think that might make things easier to read, but it might
introduce ambiguities, especially you do not control the set of
remote branches and tags.

Re: git pull and merging.

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Once you place something like "branch.*.merge" in configuration
> file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
> are talking about other repositories you regularly interact
> with, so it might be probably Ok to require the user to use a
> tracking branch if he wants the convenience of "branch.*.merge",
> and make its value name the local tracking branch instead of the
> remote branch.

In other words, I am all for fixing this.

Although it may not hurt too much if we just redefine the
meaning of it to name the local tracking branch, using a
different name "branch.*.defaultmerge" is safer and would not
break existing repositories.

Re: git pull and merging.

[Santi Béjar]

On 12/8/06, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Once you place something like "branch.*.merge" in configuration
> > file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
> > are talking about other repositories you regularly interact
> > with, so it might be probably Ok to require the user to use a
> > tracking branch if he wants the convenience of "branch.*.merge",
> > and make its value name the local tracking branch instead of the
> > remote branch.
>
> In other words, I am all for fixing this.
>
> Although it may not hurt too much if we just redefine the
> meaning of it to name the local tracking branch, using a
> different name "branch.*.defaultmerge" is safer and would not
> break existing repositories.

Or branch.*.localmerge?

Re: git pull and merging.

[Jakub Narebski]

Josef Weidendorfer wrote:

> Now looking at it, I think this semantic really is screwed and utterly confusing.
> Why decides branch.*.merge about actions done in fetch (I think even if you did
> "git fetch" alone)? OK, actually, that is an implementation detail and not
> really important.
> 
> More important: Because "branch.*.merge" specifies a _remote_ branch,
> the user has to understand that this info is already used in the fetch.
> The intuitive mental model of a user about how it works IMHO is that
> "branch.*.merge" is checked in the merge phase (as the name of the option suggests).
> But this way, how could the merge phase know about any remote branch at all,
> which does not need to be touched at all in the merge phase?
> 
> IMHO we should somehow change the semantic of branch.*.merge to specify the _local_
> refspec part, as this is the branch which actually gets merged.
> This is the only way that a user could grasp the meaning of it.
> Perhaps introduce "branch.*.defaultmerge", and obsoleting "branch.*.merge"?

The change of semantic would prohibit the "pull without tracking branch"
semantic (probably not used anymore, since git supports multiple heads
from long time).

I proposed in another thread to allow to either specify full refspec (in
addition to current specifying remote branch), or ':' and local branch.
Or perhaps add branch.*.localmerge configuration option?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git pull and merging.

[Jakub Narebski]

Aneesh Kumar wrote:

> On 12/6/06, Junio C Hamano <junkio@cox.net> wrote:
>> "Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
>>
>>> I have a git.git clone using --use-separate-remote. That means i have
>>> the master branch created by default. Now i need to build git from the
>>> pu branch too. So i created git branch pu remotes/origin/pu.
>>>
>>>
>>> How how do i track the pu branch using git pull. What i mean is the
>>> master local branch is tracked by default using git pull. Is there a
>>> way to track the local pu branch too.
>>
>>         $ cat>.git/remotes/origin <<\EOF
>>         URL: ...kernel.org/pub/scm/git/git.git
>>         Pull: refs/heads/master:refs/remotes/origin/master
>>         Pull: refs/heads/next:refs/remotes/origin/next
>>         Pull: +refs/heads/pu:refs/remotes/origin/pu
>>         EOF

Or you can do .git/config equivalent:

$ git repo-config remote.origin.url ...kernel.org/pub/scm/git/git.git
$ git repo-config remote.origin.fetch  refs/heads/master:refs/remotes/origin/master
$ git repo-config remote.origin.fetch  refs/heads/next:refs/remotes/origin/next
$ git repo-config remote.origin.fetch +refs/heads/pu:refs/remotes/origin/pu

>> Then you would checkout 'pu' by having a matching local branch:
>>
>>         $ git branch pu remotes/origin/pu
>>         $ git checkout pu ;# this is your refs/heads/pu
>>         $ make
>>
>> Hacking on it can be done in this branch as usual.  When you are
>> interested in the latest 'pu' from me:
>>
>>         $ git checkout pu ;# this is your refs/heads/pu
>>         $ git fetch ;# most of the time git pull would also be fine...
>>
>> and then:
>>
>>         $ git rebase remotes/origin/pu
>>
>> The 'rebase' in the last step is because my 'pu' rewinds freely;
>> otherwise you would do "git merge remotes/origin/pu" instead.
>>
> 
> Okey what i was looking for was a .git/config that will imply as a
> part of git pull origin that local
> 
> master is to track remotes/origin/master
> pu  should track remotes/origin/pu.
> 
> I almost felt the branch.<name>.merge was for that.
> 
> What is this git-repo-config used for. I am trying to understand
> 
> branch.<name>.remote and branch.<name>.merge usage.

Yes it is what branch.<name>.merge is for... and it would work for
any branch _except_ pu, which rewinds frequently, and you should
rebase your changes on top of current version instead of merging.

Still it is useful to add branch.<branch>.remote for pu:

  $ git repo-config branch.refs/heads/pu.remote origin

so you can do just "git fetch" on pu to fetch from origin (well,
"git fetch" would fetch from origin as it is the default even in
absence of branch.<branch>.remote).

If it were any other branch, for example next, you could add

  $ git repo-config branch.refs/heads/next.remote origin
  $ git repo-config branch.refs/heads/next.merge refs/remotes/origin/next

for "git pull" on next branch fo fetch from origin and merge
next branch from origin. 

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git pull and merging.

[Johannes Schindelin]

Hi,

On Wed, 6 Dec 2006, Jakub Narebski wrote:

> $ git repo-config remote.origin.fetch  refs/heads/master:refs/remotes/origin/master
> $ git repo-config remote.origin.fetch  refs/heads/next:refs/remotes/origin/next

Oops. You want to append "^$" at the end (otherwise the "master" entry is 
overwritten; remote.origin.fetch is a multivalued key). Same for "pu".

Ciao,