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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html