Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> writes: > On Friday 22 December 2006 07:00, Junio C Hamano wrote: >> Junio C Hamano <junkio@xxxxxxx> 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. - 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