threads / discuss / 6054

Re: warning merge message

Subject: Re: warning merge message

## tl;dr

11 messages between Dec 20, 2006 and Dec 23, 2006.

replies: 10people: 5as markdown or json

Luben Tuikov· Dec 20, 2006, 21:22 UTC · lore

warning merge message

Hi,
Can we please eliminate this f@#$ing message:
Warning: No merge candidate found because value of config option
         "branch.master.merge" does not match any remote branch fetched.
This message simply means:
Warning: you're not conforming to some merge policy that I've
     set forth in such and such of my patches committed to git.

If the default behavior is the old, current, well established behavior, then I see no reason for this "scary" f@#$ing message to be printed, "warning" me of some "problem".

Thanks!
    Luben
Johannes Schindelin· Dec 21, 2006, 09:23 UTC · re: Luben Tuikov · lore
Hi,
On Wed, 20 Dec 2006, Luben Tuikov wrote:
> Can we please eliminate this f@#$ing message:
> Warning: No merge candidate found because value of config option
>          "branch.master.merge" does not match any remote branch fetched.

Well, you can always tell git explicitely what you want. I.e. specify the remote _and_ the branch you want to merge.

BTW I am still waiting for your test results regarding the segmentation fault of merge-recursive.

Ciao, Dscho

Luben Tuikov· Dec 22, 2006, 00:25 UTC · re: Johannes Schindelin · lore
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 6 quoted lines
> > Can we please eliminate this f@#$ing message:
> > Warning: No merge candidate found because value of config option
> >          "branch.master.merge" does not match any remote branch fetched.
> 
> Well, you can always tell git explicitely what you want. I.e. specify the 
> remote _and_ the branch you want to merge.
What would be that setting if I want the default behavior?

Is this "merge candidate let-me-impose-my-workflow-on-you" merge a single step or does it also checkout as the default behavior: fast forward local origin to remote master, merge local origin to local master, check out master?

> BTW I am still waiting for your test results regarding the segmentation 
> fault of merge-recursive.

I'm swamped. Did you say you have no 64 bit machines you can try it on? Also, I don't mind giving you my dev tree, but currently I don't export it anywhere. BTW, I've seen this bug on 64 bit machines. I've not tried it on 32.

    Luben
Shawn Pearce· Dec 22, 2006, 00:43 UTC · re: Luben Tuikov · lore
Luben Tuikov <ltuikov@yahoo.com> wrote:
> I'm swamped.  Did you say you have no 64 bit machines you can try it on?
> Also, I don't mind giving you my dev tree, but currently I don't export
> it anywhere.  BTW, I've seen this bug on 64 bit machines.  I've not tried
> it on 32.

I have an amd64 here that I need to finish configuring. Its running well enough however that I could debug this issue on that machine if I could get the branches in question.

merge-recursive and the xdl_merge() routine aren't exactly my area of expertise, but if Johannes can't do it I'll step up and see what I can do.

-- 
Shawn.
Junio C Hamano· Dec 22, 2006, 00:49 UTC · re: Luben Tuikov · lore
Luben Tuikov <ltuikov@yahoo.com> writes:
> Can we please eliminate this message:
> Warning: No merge candidate found because value of config option
>          "branch.master.merge" does not match any remote branch fetched.

The above message was meant only for "git pull", but was leaked even when you did "git fetch"; it was a bug and was corrected already (hopefully).

Junio C Hamano· Dec 22, 2006, 06:00 UTC · re: Junio C Hamano · lore
Junio C Hamano <junkio@cox.net> writes:
Show 9 quoted lines
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> Can we please eliminate this message:
>> Warning: No merge candidate found because value of config option
>>          "branch.master.merge" does not match any remote branch fetched.
>
> The above message was meant only for "git pull", but was leaked
> even when you did "git fetch"; it was a bug and was corrected
> already (hopefully).
Gaah... it turns out that it was not fixed properly.
Let's do this until we figure out what the correct fix would be.
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index ea7511e..871c08f 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -141,8 +141,7 @@ canon_refs_list_for_fetch () {
 			curr_branch=$(git-symbolic-ref HEAD | \
 			    sed -e 's|^refs/heads/||')
 			merge_branches=$(git-repo-config \
-			    --get-all "branch.${curr_branch}.merge") ||
-			merge_branches=.this.would.never.match.any.ref.
+			    --get-all "branch.${curr_branch}.merge")
 		fi
 		set x $(expand_refs_wildcard "$@")
 		shift
Josef Weidendorfer· Dec 22, 2006, 20:42 UTC · re: Junio C Hamano · lore
On Friday 22 December 2006 07:00, Junio C Hamano wrote:
Show 13 quoted lines
> Junio C Hamano <junkio@cox.net> writes:
> 
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> Can we please eliminate this message:
> >> Warning: No merge candidate found because value of config option
> >>          "branch.master.merge" does not match any remote branch fetched.
> >
> > The above message was meant only for "git pull", but was leaked
> > even when you did "git fetch"; it was a bug and was corrected
> > already (hopefully).
> 
> Gaah... it turns out that it was not fixed properly.

Sorry, I am missing something. What is the exact problem that goes wrong here?

The message is printed when "git pull [args]" does not result in any merge with current branch. What is wrong about this? But a "git pull ..." always should lead to some merge in the end in every possible work flow, or should it not?

Josef
Junio C Hamano· Dec 22, 2006, 21:12 UTC · re: Josef Weidendorfer · lore
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
Show 10 quoted lines
> On Friday 22 December 2006 07:00, Junio C Hamano wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>> 
>> > The above message was meant only for "git pull", but was leaked
>> > even when you did "git fetch"; it was a bug and was corrected
>> > already (hopefully).
>> 
>> Gaah... it turns out that it was not fixed properly.
>
> Sorry, I am missing something.

You are not missing anything -- I CC'ed you not because I meant to point fingers at you but I hoped you had better ideas since you touched the related logic recently.

> What is the exact problem that goes wrong here?

The problem is the same as on another thread where Merlyn got his scripts broken. It is not _issuing_ the warning that is wrong anymore, but is about deciding how to decide that no merge candidate should exist.

We used to always merge with the first set of branches (either the first "Pull: " line in remotes/$origin or the first instance of "remotes.$origin.fetch" configuration). Santi then added "branch.$current.merge" to override that depending on what branch we are currently on, which was backward compatible -- without such a configuration, we still used the "first set of branches" rule.

People for a long time observed "the first set of branches" rule was often a wrong thing to do while on a branch other than 'master' (but we do not want to add hardcoded 'master' unnecessarily), and I recently screwed up by changing the logic in such a way that everything is marked as not-for-merge unless branches.*.merge is not set when pulling from the default remote, which was completely bogus and bitten Luben.

Josef Weidendorfer· Dec 22, 2006, 22:49 UTC · re: Junio C Hamano · lore
On Friday 22 December 2006 22:12, Junio C Hamano wrote:
Show 7 quoted lines
> People for a long time observed "the first set of branches" rule
> was often a wrong thing to do while on a branch other than
> 'master' (but we do not want to add hardcoded 'master'
> unnecessarily), and I recently screwed up by changing the logic
> in such a way that everything is marked as not-for-merge unless
> branches.*.merge is not set when pulling from the default
> remote,
Ah, yes.

I saw your patch and thought: Wow, that means to fully throw away the previous behavior, which could upset people ;-) But then I thought: Hmm... probably on purpose, as this "the first set of branches" rule really was strange.

> which was completely bogus and bitten Luben.

So I see you actually _wanted_ to keep old behavior for existing repositories.

In a previous discussion, you talked about switching to the new behavior (ie. getting rid of this "first set of branches" rule) when there is at least one branch.*.merge setting in the config file.

Unfortunately I can not see an easy way to check this with repo-config, as there is no wildcard support for keys (Ok, I can do a list of keys and grep).

I think it is better to provide an option "pull.do-not-follow-the-first-set-of-branches-rule". And we should make this the default after init-db or clone.

Josef
Junio C Hamano· Dec 22, 2006, 23:00 UTC · re: Josef Weidendorfer · lore
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
Show 8 quoted lines
> In a previous discussion, you talked about switching to
> the new behavior (ie. getting rid of this "first set of
> branches" rule) when there is at least one branch.*.merge
> setting in the config file.
>
> Unfortunately I can not see an easy way to check this with
> repo-config, as there is no wildcard support for keys
> (Ok, I can do a list of keys and grep).

I think --get-regexp is what you want -- see my "patch for discussion".

> I think it is better to provide an option
> "pull.do-not-follow-the-first-set-of-branches-rule".
> And we should make this the default after init-db or clone.
Yes, but the problem is that old timers do make new clones.
pull.i-like-the-first-set-of-branches in ~/.gitconfig is the
only thing I can think of but that is too ugly and is already on
the slippery slope of user.expert configuration which I do not
think we want.
Josef Weidendorfer· Dec 23, 2006, 00:05 UTC · re: Junio C Hamano · lore
On Saturday 23 December 2006 00:00, Junio C Hamano wrote:
Show 13 quoted lines
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> > In a previous discussion, you talked about switching to
> > the new behavior (ie. getting rid of this "first set of
> > branches" rule) when there is at least one branch.*.merge
> > setting in the config file.
> >
> > Unfortunately I can not see an easy way to check this with
> > repo-config, as there is no wildcard support for keys
> > (Ok, I can do a list of keys and grep).
> 
> I think --get-regexp is what you want -- see my "patch for
> discussion".
I see. I just read the thread.
The git mailing list is already quite high volume ;-)
Around 150+ new postings a day.
I think I first should browse through any new threads before
answering any mail.
Show 5 quoted lines
> > I think it is better to provide an option
> > "pull.do-not-follow-the-first-set-of-branches-rule".
> > And we should make this the default after init-db or clone.
> 
> Yes, but the problem is that old timers do make new clones.

Yes, they do. But this is not breaking existing repositories.

If you collect such incompatibilities for the 1.5.0 release notes and provide the workaround ("remove that pull.do-not ..." option) to get back the old behavior, it should be fine.

I can imagine that we want to add branch.*.remote/merge lines with "git checkout -b XXX remotes/YYY". Of course this should only be done if the pull.do-not is set. Relying on existance branch.*.merge lines seems fragile for me.

What about putting this option into the config template instead of setting it in clone? If somebody always wants the old behavior, he should provide a template with this option not set.

> pull.i-like-the-first-set-of-branches in ~/.gitconfig is the
> only thing I can think of but that is too ugly and is already on
> the slippery slope of user.expert configuration which I do not
> think we want.
I agree.
Josef

← back to recent threads