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

-

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

-

Hi,
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 
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
-

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

-

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
-

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)
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>
-aneesh

-

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
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 use...
[ message continues ]

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

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?
Santi

-

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

-

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

It does not.
Perhaps that the branch.<name>.remote and branch.<name>.merge have the

-

On Friday 08 December 2006 02:56, Santi B

On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:

quoted text
> On Friday 08 December 2006 02:56, Santi B

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 "br...
[ message continues ]

Ack for the documentation part. But the localmerge part is almost

equivalent to my patch to allow the branch.<name>.remote equal to ".".
Santi

-

On Friday 08 December 2006 21:52, Santi B

On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:

quoted text
> On Friday 08 December 2006 21:52, Santi B

"Santi B

On Friday 08 December 2006 22:38, Junio C Hamano wrote:

quoted text
> "Santi B

>> "Santi B

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?
Josef

-

Thanks, appreciated.
-

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>

---
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" ; s...
[ message continues ]

Acked-by: Santi B