From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Fri, 22 Dec 2006 22:49:54 GMT
Subject: Re: warning merge message
Message-ID: <200612222349.54363.Josef.Weidendorfer@gmx.de>
In-Reply-To: <7vodpvy6sf.fsf@assigned-by-dhcp.cox.net>

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