{"thread":{"id":"6054","subject":"Re: warning merge message","startedAt":"2006-12-20T21:22:59Z","lastAt":"2006-12-23T00:05:01Z","messageCount":11,"participants":["Johannes Schindelin","Luben Tuikov","Shawn Pearce","Junio C Hamano","Josef Weidendorfer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296506","messageId":"867728.44872.qm@web31814.mail.mud.yahoo.com","threadId":"6054","inReplyTo":null,"subject":"warning merge message","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-12-20T21:22:59Z","receivedAt":"2006-12-20T21:22:59Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"Hi,\n\nCan we please eliminate this f@#$ing message:\nWarning: No merge candidate found because value of config option\n \"branch.master.merge\" does not match any remote branch fetched.\n\nThis message simply means:\nWarning: you're not conforming to some merge policy that I've\n set forth in such and such of my patches committed to git.\n\nIf the default behavior is the old, current, well established\nbehavior, then I see no reason for this \"scary\" f@#$ing message\nto be printed, \"warning\" me of some \"problem\".\n\nThanks!\n Luben\n"},{"id":"29921","messageId":"Pine.LNX.4.63.0612211022280.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6054","inReplyTo":"867728.44872.qm@web31814.mail.mud.yahoo.com","subject":"Re: warning merge message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-21T09:23:42Z","receivedAt":"2006-12-21T09:23:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Dec 2006, Luben Tuikov wrote:\n\n> Can we please eliminate this f@#$ing message:\n> Warning: No merge candidate found because value of config option\n> \"branch.master.merge\" does not match any remote branch fetched.\n\nWell, you can always tell git explicitely what you want. I.e. specify the \nremote _and_ the branch you want to merge.\n\nBTW I am still waiting for your test results regarding the segmentation \nfault of merge-recursive.\n\nCiao,\nDscho\n"},{"id":"29977","messageId":"121430.93915.qm@web31808.mail.mud.yahoo.com","threadId":"6054","inReplyTo":"Pine.LNX.4.63.0612211022280.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: warning merge message","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-12-22T00:25:23Z","receivedAt":"2006-12-22T00:25:23Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Johannes Schindelin wrote:\n> > Can we please eliminate this f@#$ing message:\n> > Warning: No merge candidate found because value of config option\n> > \"branch.master.merge\" does not match any remote branch fetched.\n> \n> Well, you can always tell git explicitely what you want. I.e. specify the \n> remote _and_ the branch you want to merge.\n\nWhat would be that setting if I want the default behavior?\n\nIs this \"merge candidate let-me-impose-my-workflow-on-you\" merge\na single step or does it also checkout as\nthe default behavior: fast forward local origin to remote master,\nmerge local origin to local master, check out master?\n\n> BTW I am still waiting for your test results regarding the segmentation \n> fault of merge-recursive.\n\nI'm swamped. Did you say you have no 64 bit machines you can try it on?\nAlso, I don't mind giving you my dev tree, but currently I don't export\nit anywhere. BTW, I've seen this bug on 64 bit machines. I've not tried\nit on 32.\n\n Luben\n"},{"id":"29979","messageId":"20061222004311.GC14636@spearce.org","threadId":"6054","inReplyTo":"121430.93915.qm@web31808.mail.mud.yahoo.com","subject":"Re: warning merge message","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-22T00:43:11Z","receivedAt":"2006-12-22T00:43:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Luben Tuikov wrote:\n> I'm swamped. Did you say you have no 64 bit machines you can try it on?\n> Also, I don't mind giving you my dev tree, but currently I don't export\n> it anywhere. BTW, I've seen this bug on 64 bit machines. I've not tried\n> it on 32.\n\nI have an amd64 here that I need to finish configuring. Its running\nwell enough however that I could debug this issue on that machine\nif I could get the branches in question.\n\nmerge-recursive and the xdl_merge() routine aren't exactly my area\nof expertise, but if Johannes can't do it I'll step up and see what\nI can do.\n\n-- \nShawn.\n"},{"id":"29983","messageId":"7vr6us92m2.fsf@assigned-by-dhcp.cox.net","threadId":"6054","inReplyTo":"867728.44872.qm@web31814.mail.mud.yahoo.com","subject":"Re: warning merge message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T00:49:09Z","receivedAt":"2006-12-22T00:49:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> Can we please eliminate this message:\n> Warning: No merge candidate found because value of config option\n> \"branch.master.merge\" does not match any remote branch fetched.\n\nThe above message was meant only for \"git pull\", but was leaked\neven when you did \"git fetch\"; it was a bug and was corrected\nalready (hopefully).\n"},{"id":"30015","messageId":"7v1wms79mg.fsf@assigned-by-dhcp.cox.net","threadId":"6054","inReplyTo":"7vr6us92m2.fsf@assigned-by-dhcp.cox.net","subject":"Re: warning merge message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T06:00:39Z","receivedAt":"2006-12-22T06:00:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Luben Tuikov writes:\n>\n>> Can we please eliminate this message:\n>> Warning: No merge candidate found because value of config option\n>> \"branch.master.merge\" does not match any remote branch fetched.\n>\n> The above message was meant only for \"git pull\", but was leaked\n> even when you did \"git fetch\"; it was a bug and was corrected\n> already (hopefully).\n\nGaah... it turns out that it was not fixed properly.\n\nLet's do this until we figure out what the correct fix would be.\n\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex ea7511e..871c08f 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -141,8 +141,7 @@ canon_refs_list_for_fetch () {\n \t\t\tcurr_branch=$(git-symbolic-ref HEAD | \\\n \t\t\t sed -e 's|^refs/heads/||')\n \t\t\tmerge_branches=$(git-repo-config \\\n-\t\t\t --get-all \"branch.${curr_branch}.merge\") ||\n-\t\t\tmerge_branches=.this.would.never.match.any.ref.\n+\t\t\t --get-all \"branch.${curr_branch}.merge\")\n \t\tfi\n \t\tset x $(expand_refs_wildcard \"$@\")\n \t\tshift\n"},{"id":"30094","messageId":"200612222142.15489.Josef.Weidendorfer@gmx.de","threadId":"6054","inReplyTo":"7v1wms79mg.fsf@assigned-by-dhcp.cox.net","subject":"Re: warning merge message","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-22T20:42:15Z","receivedAt":"2006-12-22T20:42:15Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 22 December 2006 07:00, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Luben Tuikov writes:\n> >\n> >> Can we please eliminate this message:\n> >> Warning: No merge candidate found because value of config option\n> >> \"branch.master.merge\" does not match any remote branch fetched.\n> >\n> > The above message was meant only for \"git pull\", but was leaked\n> > even when you did \"git fetch\"; it was a bug and was corrected\n> > already (hopefully).\n> \n> Gaah... it turns out that it was not fixed properly.\n\nSorry, I am missing something.\nWhat is the exact problem that goes wrong here?\n\nThe message is printed when \"git pull [args]\" does not result\nin any merge with current branch. What is wrong about this?\nBut a \"git pull ...\" always should lead to some merge\nin the end in every possible work flow, or should it not?\n\nJosef\n"},{"id":"30102","messageId":"7vodpvy6sf.fsf@assigned-by-dhcp.cox.net","threadId":"6054","inReplyTo":"200612222142.15489.Josef.Weidendorfer@gmx.de","subject":"Re: warning merge message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T21:12:00Z","receivedAt":"2006-12-22T21:12:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> On Friday 22 December 2006 07:00, Junio C Hamano wrote:\n>> Junio C Hamano writes:\n>> \n>> > The above message was meant only for \"git pull\", but was leaked\n>> > even when you did \"git fetch\"; it was a bug and was corrected\n>> > already (hopefully).\n>> \n>> Gaah... it turns out that it was not fixed properly.\n>\n> Sorry, I am missing something.\n\nYou are not missing anything -- I CC'ed you not because I meant\nto point fingers at you but I hoped you had better ideas since\nyou touched the related logic recently.\n\n> What is the exact problem that goes wrong here?\n\nThe problem is the same as on another thread where Merlyn got\nhis scripts broken. It is not _issuing_ the warning that is\nwrong anymore, but is about deciding how to decide that no merge\ncandidate should exist.\n\nWe used to always merge with the first set of branches (either\nthe first \"Pull: \" line in remotes/$origin or the first instance\nof \"remotes.$origin.fetch\" configuration). Santi then added\n\"branch.$current.merge\" to override that depending on what\nbranch we are currently on, which was backward compatible --\nwithout such a configuration, we still used the \"first set of\nbranches\" rule.\n\nPeople for a long time observed \"the first set of branches\" rule\nwas often a wrong thing to do while on a branch other than\n'master' (but we do not want to add hardcoded 'master'\nunnecessarily), and I recently screwed up by changing the logic\nin such a way that everything is marked as not-for-merge unless\nbranches.*.merge is not set when pulling from the default\nremote, which was completely bogus and bitten Luben.\n"},{"id":"30124","messageId":"200612222349.54363.Josef.Weidendorfer@gmx.de","threadId":"6054","inReplyTo":"7vodpvy6sf.fsf@assigned-by-dhcp.cox.net","subject":"Re: warning merge message","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-22T22:49:54Z","receivedAt":"2006-12-22T22:49:54Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 22 December 2006 22:12, Junio C Hamano wrote:\n> People for a long time observed \"the first set of branches\" rule\n> was often a wrong thing to do while on a branch other than\n> 'master' (but we do not want to add hardcoded 'master'\n> unnecessarily), and I recently screwed up by changing the logic\n> in such a way that everything is marked as not-for-merge unless\n> branches.*.merge is not set when pulling from the default\n> remote,\n\nAh, yes.\n\nI saw your patch and thought: Wow, that means to fully throw\naway the previous behavior, which could upset people ;-)\nBut then I thought: Hmm... probably on purpose, as this\n\"the first set of branches\" rule really was strange.\n\n> which was completely bogus and bitten Luben. \n\nSo I see you actually _wanted_ to keep old behavior\nfor existing repositories.\n\nIn a previous discussion, you talked about switching to\nthe new behavior (ie. getting rid of this \"first set of\nbranches\" rule) when there is at least one branch.*.merge\nsetting in the config file.\n\nUnfortunately I can not see an easy way to check this with\nrepo-config, as there is no wildcard support for keys\n(Ok, I can do a list of keys and grep).\n\nI think it is better to provide an option\n\"pull.do-not-follow-the-first-set-of-branches-rule\".\nAnd we should make this the default after init-db or clone.\n\nJosef\n"},{"id":"30126","messageId":"7vy7ozv8lz.fsf@assigned-by-dhcp.cox.net","threadId":"6054","inReplyTo":"200612222349.54363.Josef.Weidendorfer@gmx.de","subject":"Re: warning merge message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T23:00:56Z","receivedAt":"2006-12-22T23:00:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer writes:\n\n> In a previous discussion, you talked about switching to\n> the new behavior (ie. getting rid of this \"first set of\n> branches\" rule) when there is at least one branch.*.merge\n> setting in the config file.\n>\n> Unfortunately I can not see an easy way to check this with\n> repo-config, as there is no wildcard support for keys\n> (Ok, I can do a list of keys and grep).\n\nI think --get-regexp is what you want -- see my \"patch for\ndiscussion\".\n\n> I think it is better to provide an option\n> \"pull.do-not-follow-the-first-set-of-branches-rule\".\n> And we should make this the default after init-db or clone.\n\nYes, but the problem is that old timers do make new clones.\n\npull.i-like-the-first-set-of-branches in ~/.gitconfig is the\nonly thing I can think of but that is too ugly and is already on\nthe slippery slope of user.expert configuration which I do not\nthink we want.\n \n"},{"id":"30132","messageId":"200612230105.01408.Josef.Weidendorfer@gmx.de","threadId":"6054","inReplyTo":"7vy7ozv8lz.fsf@assigned-by-dhcp.cox.net","subject":"Re: warning merge message","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-23T00:05:01Z","receivedAt":"2006-12-23T00:05:01Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 23 December 2006 00:00, Junio C Hamano wrote:\n> Josef Weidendorfer writes:\n> \n> > In a previous discussion, you talked about switching to\n> > the new behavior (ie. getting rid of this \"first set of\n> > branches\" rule) when there is at least one branch.*.merge\n> > setting in the config file.\n> >\n> > Unfortunately I can not see an easy way to check this with\n> > repo-config, as there is no wildcard support for keys\n> > (Ok, I can do a list of keys and grep).\n> \n> I think --get-regexp is what you want -- see my \"patch for\n> discussion\".\n\nI see. I just read the thread.\n\nThe git mailing list is already quite high volume ;-)\nAround 150+ new postings a day.\nI think I first should browse through any new threads before\nanswering any mail.\n \n> > I think it is better to provide an option\n> > \"pull.do-not-follow-the-first-set-of-branches-rule\".\n> > And we should make this the default after init-db or clone.\n> \n> Yes, but the problem is that old timers do make new clones.\n\nYes, they do.\nBut this is not breaking existing repositories.\n\nIf you collect such incompatibilities for the 1.5.0 release\nnotes and provide the workaround (\"remove that pull.do-not ...\"\noption) to get back the old behavior, it should be fine.\n\nI can imagine that we want to add branch.*.remote/merge lines\nwith \"git checkout -b XXX remotes/YYY\". Of course this should\nonly be done if the pull.do-not is set. Relying on existance\nbranch.*.merge lines seems fragile for me.\n\nWhat about putting this option into the config template instead of\nsetting it in clone?\nIf somebody always wants the old behavior, he should provide a template\nwith this option not set.\n\n> pull.i-like-the-first-set-of-branches in ~/.gitconfig is the\n> only thing I can think of but that is too ugly and is already on\n> the slippery slope of user.expert configuration which I do not\n> think we want.\n\nI agree.\n\nJosef\n"}]}