Re: warning merge message

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Dec 22, 2006, 22:49 UTC
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:

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