Re: git pull and merging.

Josef Weidendorfer [off-list ref] 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".

On Friday 08 December 2006 21:52, Santi Béjar wrote:

On 12/8/06, Josef Weidendorfer [off-list ref] wrote:

quoted

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

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?

On 12/8/06, Josef Weidendorfer [off-list ref] 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 <redacted>

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

On 12/8/06, Josef Weidendorfer [off-list ref] wrote:

On Friday 08 December 2006 02:56, Santi Béjar wrote:

quoted

quoted

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

quoted

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.

quoted

quoted

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.

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

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)

-- 

On 12/7/06, Josef Weidendorfer [off-list ref] wrote:

On Thursday 07 December 2006 20:06, you wrote:

quoted

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

On 12/8/06, Josef Weidendorfer [off-list ref] wrote:

On Friday 08 December 2006 21:52, Santi Béjar wrote:

quoted

On 12/8/06, Josef Weidendorfer [off-list ref] wrote:

quoted

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

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.

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

On Friday 08 December 2006 02:56, Santi Béjar wrote:

quoted

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

quoted

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.

quoted

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