warning merge message

warning merge message

[Luben Tuikov]

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

Re: warning merge message

[Johannes Schindelin]

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

Re: warning merge message

[Luben Tuikov]

--- Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

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

Re: warning merge message

[Shawn Pearce]

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.

Re: warning merge message

[Junio C Hamano]

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

Re: warning merge message

[Junio C Hamano]

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.

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

Re: warning merge message

[Josef Weidendorfer]

On Friday 22 December 2006 07:00, Junio C Hamano wrote:
> 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

Re: warning merge message

[Junio C Hamano]

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

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

Re: warning merge message

[Josef Weidendorfer]

On Friday 22 December 2006 22:12, Junio C Hamano wrote:
> 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

Re: warning merge message

[Junio C Hamano]

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

Re: warning merge message

[Josef Weidendorfer]

On Saturday 23 December 2006 00:00, Junio C Hamano wrote:
> 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.
 
> > 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

Re: warning merge message

[Luben Tuikov]

Furthermore, isn't the local origin fast forwarded to the
remote master, and then the local origin merged into the
local master and then the master checked out (presumably
the user hasn't edited contents of their master branch).

This "warning" message is confusing and the branch.<branch>.merge
config option poorly documented.

Can someone clarify these things to me please?

Thanks,
    Luben