{"thread":{"id":"5056","subject":"git merge (resolve) _is_ stupid","startedAt":"2006-07-31T08:44:58Z","lastAt":"2006-07-31T17:12:29Z","messageCount":5,"participants":["Junio C Hamano","Johannes Schindelin","Luben Tuikov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"24416","messageId":"7v7j1u88ol.fsf@assigned-by-dhcp.cox.net","threadId":"5056","inReplyTo":null,"subject":"git merge (resolve) _is_ stupid","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-31T08:44:58Z","receivedAt":"2006-07-31T08:44:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"While dealing with Jakub's gitweb changes, I found that merge we\nuse _is_ very stupid. Perhaps it is not a surprise...\n\nMy \"next\" was at 688a750, and \"master\" was at b63fafd. I had\nalready merged gitweb changes from Luben to \"master\" at this\npoint, and \"next\" was in sync with \"master\" with respect to\ngitweb/, i.e. this gave empty:\n\n\t$ git diff master next gitweb/\n\nJakub's gitweb changes were stored in jn/web branch which\ncontained 16 patches on top of \"master\".\n\nHowever, pulling \"jn/web\" (594e212) into \"next\" using resolve\nstrategy produced interesting conflicts. Essentially, it said\nthat some changes done by Luben (which has already merged to\n\"master\" and precedes what Jakub did in \"jn/web\") conflict with\nwhat \"jn/web\" does, which is quite bogus.\n\nThis merge has three merge-bases, but\n\n\t$ git log master..next -- gitweb/\n\nshows only two merges, and that is not so surprising given that\nat this point gitweb/ files are identical between master and\nnext.\n\nMore interestingly, if I merge \"master\" to \"next\" first and then\nmerge \"jn/web\" on top of the result, the resolve strategy does\nthe right thing. This is understandable -- by merging \"master\"\ninto \"next\", merge base between \"next\" and \"jn/web\" becomes\n\"master\" and nothing else.\n\nUsing recursive strategy resolved this merge correctly, taking\ngitweb/ files from \"jn/web\" branch.\n\nBy the way, the \"recur\" strategy in \"next\" produces the correct\nresult, but it produces a funny error in the middle (that is why\nJohannes is CC'ed).\n\n\terror: Could not read 0100000000000000000000000000000000000000\n\n: gitster; git merge -s recur 'test merge' next jn/web\nMerging next with 594e212bc849039a204deef1d16c2eddcc451532\nMerging:\n688a75071490101dbc660e3304aafb7a13e28807 Merge branch '__/setup-n-mv' into next\n594e212bc849039a204deef1d16c2eddcc451532 gitweb: Ref refactoring - use git_get_referencing for marking tagged/head commits\nfound 3 common ancestor(s):\n7061cf0f205e86613c3a3306fdfedf2a5dcc8a65 Merge branch 'lt/setup' into __/setup-n-mv\nacb0f6f33760b43c1fc9617a45346ab3738f021a gitweb.cgi: git_blame2: slight optimization reading the blame lines\n2d023581c9a0ae5efdebfd0084d54d09669a25d5 Set datarootdir in config.mak.in\n Merging:\n 7061cf0f205e86613c3a3306fdfedf2a5dcc8a65 Merge branch 'lt/setup' into __/setup-n-mv\n acb0f6f33760b43c1fc9617a45346ab3738f021a gitweb.cgi: git_blame2: slight optimization reading the blame lines\n found 1 common ancestor(s):\n 634331061599a82968daddae2d2c0896b6137d4c gitweb.cgi: Centralize printing of the page path\n Auto-merging gitweb/gitweb.cgi\n Merging:\n virtual merged tree\n 2d023581c9a0ae5efdebfd0084d54d09669a25d5 Set datarootdir in config.mak.in\nerror: Could not read 0100000000000000000000000000000000000000\n found 1 common ancestor(s):\n 7b8cf0cf2973cc8df3bdd36b9b36542b1f04d70a Rename man1 and man7 variables to man1dir and man7dir\n Auto-merging .gitignore\n Auto-merging INSTALL\n Auto-merging Makefile\nAuto-merging Makefile\nMerge made by recur.\n Documentation/git-tar-tree.txt | 5 \n Makefile | 3 \n git.c | 76 ++---\n gitweb/gitweb.cgi | 609 +++++++++++++++++-----------------------\n setup.c | 4 \n 5 files changed, 300 insertions(+), 397 deletions(-)\n"},{"id":"24423","messageId":"Pine.LNX.4.63.0607311236070.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5056","inReplyTo":"7v7j1u88ol.fsf@assigned-by-dhcp.cox.net","subject":"Re: git merge (resolve) _is_ stupid","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-31T10:42:35Z","receivedAt":"2006-07-31T10:42:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 31 Jul 2006, Junio C Hamano wrote:\n\n> By the way, the \"recur\" strategy in \"next\" produces the correct\n> result, but it produces a funny error in the middle (that is why\n> Johannes is CC'ed).\n> \n> \terror: Could not read 0100000000000000000000000000000000000000\n\nI get \"0000000100...\" ;-) (surprixse her wi1h a big-endian ;-)\n\nThe culprit is the call to parse_commit() in merge_bases(). How about \nthis?\n\n-- 8< --\n[PATCH] merge-recur: virtual commits shall never be parsed\n\nIt would not make sense to parse a virtual commit, therefore set the\n\"parsed\" flag to 1.\n\nSigned-off-by: Johannes Schindelin \n---\n merge-recursive.c | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex 10bce70..74a329f 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -43,6 +43,8 @@ static struct commit *make_virtual_commi\n \tcommit->tree = tree;\n \tcommit->util = (void*)comment;\n \t*(int*)commit->object.sha1 = virtual_id++;\n+\t/* avoid warnings */\n+\tcommit->object.parsed = 1;\n \treturn commit;\n }\n \n-- \n1.4.2.rc2.gfd00-dirty\n"},{"id":"24427","messageId":"7v7j1u6nsx.fsf@assigned-by-dhcp.cox.net","threadId":"5056","inReplyTo":"Pine.LNX.4.63.0607311236070.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git merge (resolve) _is_ stupid","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-31T11:01:18Z","receivedAt":"2006-07-31T11:01:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The culprit is the call to parse_commit() in merge_bases(). How about \n> this?\n\nDo you mean merge_bases() in commit.c which is called by\nget_merge_bases()? If so the patch feels like papering over a\nmore grave bug -- the result from make_virtual_commit does not\nseem to have any proper parent information, so how is merge_bases()\nexpected to return anything sensible?\n\nI am confused, but going to bed first.\n"},{"id":"24428","messageId":"Pine.LNX.4.63.0607311307350.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5056","inReplyTo":"7v7j1u6nsx.fsf@assigned-by-dhcp.cox.net","subject":"Re: git merge (resolve) _is_ stupid","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-31T11:13:04Z","receivedAt":"2006-07-31T11:13:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 31 Jul 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > The culprit is the call to parse_commit() in merge_bases(). How about \n> > this?\n> \n> Do you mean merge_bases() in commit.c which is called by\n> get_merge_bases()?\n\nYes, the same.\n\n> If so the patch feels like papering over a more grave bug -- the result \n> from make_virtual_commit does not seem to have any proper parent \n> information, so how is merge_bases() expected to return anything \n> sensible?\n\nIt is not a grave bug, but very much by design: remember, a recursive \nmerge means that if you have more than one merge base, then the merge \nbases are merged first. And the result is -- tada -- a virtual commit.\n\nIt does have (virtual) parents, but we do _not_ want to traverse them in \nmerge_bases().\n\nHowever, they have (virtual) children, and _these_ relationships are \nimportant: in your case (I guess) that the merge_bases() finds the \nvirtual commit, since (with the virtual history) the other commit \nis just a fast-forward.\n\nSo, a virtual commit is something like a merge base combining two or more \nmerge bases.\n\n> I am confused, but going to bed first.\n\nI know the feeling ;-)\n\nCiao,\nDscho\n"},{"id":"24442","messageId":"20060731171229.24870.qmail@web31802.mail.mud.yahoo.com","threadId":"5056","inReplyTo":"7v7j1u88ol.fsf@assigned-by-dhcp.cox.net","subject":"Re: git merge (resolve) _is_ stupid","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-07-31T17:12:29Z","receivedAt":"2006-07-31T17:12:29Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"I had seen something similar:\n\nMerging linux-scsi into my own branches whereby both had a\nparticular patch (03aba2f79594ca94d159c8bab454de9bcc385b76),\ngit-merge complained that a resolve is needed.\n\nAfter manually \"resolving\" the result was identical to\neither branch (linux-scsi and my own), so in fact the\ndiff was 0.\n\nI found this strange, but due to lack of time couldn't\npursue it further.\n\n Luben\n"}]}