{"thread":{"id":"3688","subject":"Bad merging with stgit or git","startedAt":"2006-03-21T19:34:13Z","lastAt":"2006-03-21T23:02:19Z","messageCount":8,"participants":["Mauro Carvalho Chehab","J. Bruce Fields","Linus Torvalds","Petr Baudis","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17735","messageId":"1142969653.4749.109.camel@praia","threadId":"3688","inReplyTo":null,"subject":"Bad merging with stgit or git","fromName":"Mauro Carvalho Chehab","fromEmail":"mchehab@infradead.org","sentAt":"2006-03-21T19:34:13Z","receivedAt":"2006-03-21T19:34:13Z","isPatch":false,"sender":{"key":"mchehab@infradead.org","avatar":"https://gravatar.com/avatar/a5917da3c72777662879f8e9173af76cdcd486e857018240ef18413670127857?d=mp&s=160"},"body":"I have a -git tree that generated a really bad result when committed by\nLinus, generating a really bad history log. My tree is located at:\nkernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git.\n\nI'll try to make a brief from what's happened:\n\nAccording to him:\n\"\n...\nIn particular, commit e338b736f1aee59b757130ffdc778538b7db18d6 is crap,\ncrap, CRAP.\nIt's \"Merging Linus tree\", but it's not a merge at all: you have just \napplied the _patch_ to merge the changes in my tree, but you haven't \nactually told git to do so.\n\nI don't know how/why you did that, but it's totally bogus, and I refuse\nto \npull from that tree. That's a 5000+ line diff, affecting about 180\nfiles! \n...\n\"\n\nAfter a further analysis, it seemed that a merge conflict were badly\nsolved. It is showing this message to Linus:\n\ndiff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from\ncb31c70cdf1ac7034bed5f83d543f4888c39888a)\n Author: Mauro Carvalho Chehab \n AuthorDate: Fri Mar 10 01:30:04 2006 -0300\n Commit: Mauro Carvalho Chehab \n CommitDate: Fri Mar 10 01:30:04 2006 -0300\n\n Merging Linus tree\n\n :100644 100644 be5ae600f5337dbb14daa8d4cace110486e14f79\n81bc51369f59a413108fd8b150c3090541ba49f8 M\nDocumentation/feature-removal-schedule.txt\n :100644 100644 75205391b335f85c9b8a599d0d3b4c0dd1a8b41b\nfc99075e0af47f0b73a2ae2dfb7d19920c604dea M\nDocumentation/kernel-parameters.txt\n :100644 100644 9006063e73691da7b68449955a135f7c9317e2cd\nda677f829f7689966bf09aeda6d89fc4b6a876d1 M arch/alpha/kernel/irq.c\n\nFor me, those tree last lines, don't appear. Instead, it just shows,\nwith git-show:\n\ndiff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from\ncb31c70cdf1ac7034bed5f83d543f4888c39888a)\nAuthor: Mauro Carvalho Chehab \nDate: Fri Mar 10 01:30:04 2006 -0300\n\n Merging Linus tree\n\nand a diff file, with:\n 179 files changed, 1274 insertions(+), 785 deletions(-)\n\nWith git-cat-file, it shows:\n\n$ git-cat-file commit e338b736f1aee59b757130ffdc778538b7db18d6\ntree b233a18f740a2883e4863506175f671d821f1e5e\nparent cb31c70cdf1ac7034bed5f83d543f4888c39888a\nauthor Mauro Carvalho Chehab 1141965004 -0300\ncommitter Mauro Carvalho Chehab 1141965004 -0300\n\nMerging Linus tree\n\nIt shouldn't have any conflicts here for Linus, since those patches came\nfrom his tree.\n\nMy current procedure is:\n\nbranch origin - Linus tree replica\nbranch work - my stgit main tree\nbranch work-fixes - my stgit tree for bug fixes\nbranch master - patches to current kernel\nbranch devel - patches to next kernel\n\nAll patches are generated against work branch, with stgit.\nBranch work-fixes receives patches by using:\n\n stg pick @work\n\nBefore commiting to kernel.org, I do:\nat origin:\n git pull linus_tree\n\nat master:\n git pull . origin\n git pull . work-fixes\n\nat devel:\n git pull . origin\n git pull . work\n\nMy environment is:\n\nStacked GIT 0.8.1\ngit version 1.2.4.gfd662\nPython version 2.4.2 (#2, Jan 30 2006, 18:33:58)\n[GCC 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1)]\n\nAny ideas?\n"},{"id":"17736","messageId":"20060321193924.GD14579@fieldses.org","threadId":"3688","inReplyTo":"1142969653.4749.109.camel@praia","subject":"Re: Bad merging with stgit or git","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-03-21T19:39:24Z","receivedAt":"2006-03-21T19:39:24Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:\n> It shouldn't have any conflicts here for Linus, since those patches came\n> from his tree.\n\nWhat do you mean by \"those patches came from his tree\"? If you're\nactually cherry-picking patches from his tree and applying them to\nyours, then you're not reproducing the same commits he has--you're just\ncreating new commits that happen to have nearly identical content.\n\n--b.\n"},{"id":"17737","messageId":"Pine.LNX.4.64.0603211138020.3622@g5.osdl.org","threadId":"3688","inReplyTo":"1142969653.4749.109.camel@praia","subject":"Re: Bad merging with stgit or git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-21T19:42:08Z","receivedAt":"2006-03-21T19:42:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:\n>\n> I have a -git tree that generated a really bad result when committed by\n> Linus, generating a really bad history log. My tree is located at:\n> kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git.\n\nHere's a mail that went to linux-kernel to explain some more..\n\nBasically, the problem is that the DVB tree has a perfectly normal commit \n(_not_ a merge commit), which has the commit message\n\n\t\"Merging Linus tree\"\n\nand is just a patch that apparently merged the changes in my tree at some \nrandom state (don't know which, since the commit isn't a merge commit, and \ndoesn't point to the parent it merged from).\n\nI thought it might be a cherry-pick of a merge, or something like that, \nbut the author/committer dates are the same, so that sounds unlikely. \nHowever, I could imagine that \"stgit\" would do something like this if/when \nit is used to cherry-pick a merge. \n\nApparently the DVB people also use Mercurial somewhere, so who knows..\n\n\t\tLinus\n\n---\nDate: Tue, 21 Mar 2006 11:32:10 -0800 (PST)\nFrom: Linus Torvalds \nSubject: Re: [PATCH 000/141] V4L/DVB updates part 1\n\nOn Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:\n> \n> Weird, I can't see all those stuff here. It shows something like\n> (running from master copy at kernel.org):\n\nI just did the raw output, so my output was from\n\n\tgit show --pretty=fuller -r e338b7\n\nwhich isn't the default, but it's useful if you want to see both committer \nand author information (and the raw format is just because I wasn't \ninterested in the diff itself, just looking at how many files where \nchanged).\n\n> So, after the merging message, I have a normal diff with:\n> \n> 179 files changed, 1274 insertions(+), 785 deletions(-)\n\nYeah, we're talking about the same commit.\n\n> Seeming all perfect from my knowledge about git.\n\nIt's a perfectly good commit. BUT IT IS NOT A MERGE, AND IT IS NOT A DIFF \nTHAT I WANT TO SEE COMING IN FROM AN OUTSIDE TREE!\n\nBasically, in the DVB tree you have absolutely _no_ business in \"merging\" \nwork from my tree as a patch, especially when the patch you merge has \nabsolutely zero to do with DVB. You just applied a 5000-line patch to the \ntree, with no merge message other than \"Merge from Linus tree\", and no \nattribution about what the f*ck was merged, and why.\n\nTHAT is the part I'm unhappy with. The git tree is not \"corrupt\" from a \ntechnical standpoint (it passes fsck). It's \"corrupt\" because it contains \na patch that shouldn't be there, that is mis-attributed, and that \nincorrectly claims to be a merge when it isn't - it's just a random patch \ngenerated against my tree.\n\n\t\tLinus\n"},{"id":"17738","messageId":"20060321200847.GS18185@pasky.or.cz","threadId":"3688","inReplyTo":"1142969653.4749.109.camel@praia","subject":"Re: Bad merging with stgit or git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-21T20:08:47Z","receivedAt":"2006-03-21T20:08:47Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Mar 21, 2006 at 08:34:13PM CET, I got a letter\nwhere Mauro Carvalho Chehab said that...\n> With git-cat-file, it shows:\n> \n> $ git-cat-file commit e338b736f1aee59b757130ffdc778538b7db18d6\n> tree b233a18f740a2883e4863506175f671d821f1e5e\n> parent cb31c70cdf1ac7034bed5f83d543f4888c39888a\n> author Mauro Carvalho Chehab 1141965004 -0300\n> committer Mauro Carvalho Chehab 1141965004 -0300\n> \n> Merging Linus tree\n\nOur IRC hypothesis:\n\ngitweb shows two commits in sequence there,\n\n\t11 days ago Mauro Carvalho ... Merge branch 'origin'\n\t11 days ago Mauro Carvalho ... Merging Linus tree\n\nwhere the \"Merge branch 'origin'\" commit is a true merge commit, but a\nrather boring one. There were conflicts during the merge, and according\nto mchebab they were \"resolved\" by (incorrectly) doing:\n\n\t...edit ...\n\tgit-commit \n\nWith the old Git version (probably v1.1.4, but I'm not so sure when\nlooking at 1.1.4's git-commit.sh), git-commit would happily do the\ncommit, but wouldn't record the commit as a merge.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time. I think\nI have forgotten this before.\n"},{"id":"17739","messageId":"1142972313.4749.123.camel@praia","threadId":"3688","inReplyTo":"20060321193924.GD14579@fieldses.org","subject":"Re: Bad merging with stgit or git","fromName":"Mauro Carvalho Chehab","fromEmail":"mchehab@infradead.org","sentAt":"2006-03-21T20:18:33Z","receivedAt":"2006-03-21T20:18:33Z","isPatch":false,"sender":{"key":"mchehab@infradead.org","avatar":"https://gravatar.com/avatar/a5917da3c72777662879f8e9173af76cdcd486e857018240ef18413670127857?d=mp&s=160"},"body":"Em Ter, 2006-03-21 às 14:39 -0500, J. Bruce Fields escreveu:\n> On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:\n> > It shouldn't have any conflicts here for Linus, since those patches came\n> > from his tree.\n> \n> What do you mean by \"those patches came from his tree\"? If you're\n> actually cherry-picking patches from his tree and applying them to\n> yours, then you're not reproducing the same commits he has--you're just\n> creating new commits that happen to have nearly identical content.\nNo, I'm not cherry-picking his patches. \n\n>From the discussions on git IRC, I think it may be caused by a bad\nprocedure when solving a conflict, after merging from Linus tree.\n\n>From what I'm understanding now, I should do, when a conflict is\ndetected:\n\nnano \ngit-update-index \ngit commit\n\nPreviously (at git 1.1.4), I was doing:\nnano \ngit commit \n\ngit 1.2.4 don't allow this bad commit syntax anymore.\n\n> \n> --b.\nCheers, \nMauro.\n"},{"id":"17740","messageId":"Pine.LNX.4.64.0603211219230.3622@g5.osdl.org","threadId":"3688","inReplyTo":"20060321200847.GS18185@pasky.or.cz","subject":"Re: Bad merging with stgit or git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-21T20:37:50Z","receivedAt":"2006-03-21T20:37:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 21 Mar 2006, Petr Baudis wrote:\n> \n> With the old Git version (probably v1.1.4, but I'm not so sure when\n> looking at 1.1.4's git-commit.sh), git-commit would happily do the\n> commit, but wouldn't record the commit as a merge.\n\nI considered that, but as far as I can tell, Mauro is actually using a \nfairly recent version of \"git\". How do I know? The second merge (the \n_real_ one) says\n\n\tcommit 86d720ef82ca09e75fac06be15da7cbe2721863a\n\tMerge: e338b73... 8fce4d8...\n\tAuthor: Mauro Carvalho Chehab \n\tDate: Fri Mar 10 01:32:32 2006 -0300\n\n\t Merge branch 'origin'\n \n\t Conflicts:\n\t \n\t drivers/media/video/saa7134/saa7134-dvb.c\n\t nothing to commit\n\nand that \"Conflicts:\" thing from git is actually reasonably recent (it's \nfrom end of January), and almost certainly doesn't exist in v1.1.4 (I \ndon't think it exists in any 1.1.x version).\n\nSo it's 1.2.0 or newer (or some random build, of course).\n\nAnd I _hope_ that no git that recent will commit a merge in progress. \n\nHowever, it does look like the \n\n\tcase \"$all,$also\" in\n\t,t)\n\ncase doesn't check for MERGE_HEAD. That could be the bug. Junio?\n\n\t\tLinus\n"},{"id":"17742","messageId":"7vy7z3ecs2.fsf@assigned-by-dhcp.cox.net","threadId":"3688","inReplyTo":"Pine.LNX.4.64.0603211219230.3622@g5.osdl.org","subject":"Re: Bad merging with stgit or git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-21T20:57:49Z","receivedAt":"2006-03-21T20:57:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And I _hope_ that no git that recent will commit a merge in progress. \n\nNot even 1.1 series for that matter, no.\n\n> However, it does look like the \n>\n> \tcase \"$all,$also\" in\n> \t,t)\n>\n> case doesn't check for MERGE_HEAD. That could be the bug. Junio?\n\nI do not think so. \n\n\"Also\" (aka -i) means \"run update-index for these paths for me\nfirst, and commit them alongside with what I (or merge) have\nalready updated in the index\".\n"},{"id":"17746","messageId":"7vfylbcsg4.fsf@assigned-by-dhcp.cox.net","threadId":"3688","inReplyTo":"1142972313.4749.123.camel@praia","subject":"Re: Bad merging with stgit or git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-21T23:02:19Z","receivedAt":"2006-03-21T23:02:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mauro Carvalho Chehab writes:\n\n>From what I'm understanding now, I should do, when a conflict is\n> detected:\n>\n> nano \n> git-update-index \n> git commit\n>\n> Previously (at git 1.1.4), I was doing:\n> nano \n> git commit \n>\n> git 1.2.4 don't allow this bad commit syntax anymore.\n\nIt is not a bad syntax, and it instead would say \"you might have\nmeant to say -i paths...\", and if you follow that suggestion to\nsay:\n\n\t$ git commit -i this-and-that-file-I-resolved-by-hand\n\nyou would commit the cleanly auto-resolved paths _and_ the\nresult of your hand merge result. That is the same traditional\nbehaviour you are used to and is very convenient if you only had\na few paths to be hand resolved.\n\nSo I suspect there might be something else going on.\n"}]}