{"thread":{"id":"1730","subject":"bogus merges","startedAt":"2005-09-05T14:38:29Z","lastAt":"2005-09-12T00:58:07Z","messageCount":13,"participants":["Wayne Scott","Linus Torvalds","Daniel Barkalow","Russell King","Martin Langhoff","A Large Angry SCM","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8086","messageId":"59a6e58305090507387d412b3d@mail.gmail.com","threadId":"1730","inReplyTo":null,"subject":"bogus merges","fromName":"Wayne Scott","fromEmail":"wsc9tt@gmail.com","sentAt":"2005-09-05T14:38:29Z","receivedAt":"2005-09-05T14:38:29Z","isPatch":false,"sender":{"key":"wsc9tt@gmail.com","avatar":"https://gravatar.com/avatar/2418bf5fa7f1625a2b9dd049db4ab56110f561610421d6f2559f7c018ce53eb3?d=mp&s=160"},"body":"A recent commit in linux-2.6 looks like this:\n\ncommit b129a8ccd53f74c43e4c83c8e0031a4990040830\nMerge: 6b39374a27eb4be7e9d82145ae270ba02ea90dc8\n194d0710e1a7fe92dcf860ddd31fded8c3103b7a\nAuthor: Russell King <rmk@dyn-67.arm.linux.org.uk>\nDate:   Wed Aug 31 10:12:14 2005 +0100\n\n    [SERIAL] Clean up and fix tty transmission start/stoping\n    \nThe problem is that two parents of this merge are separate.  One is an\nancestor of the other.  This means the merge is really pointless and\nprobably accidental.\n\nReally 'git commit' should detect problems like this automatically and\nprevent them from getting in the tree.\n\n-Wayne\n"},{"id":"8094","messageId":"Pine.LNX.4.58.0509050853080.3568@evo.osdl.org","threadId":"1730","inReplyTo":"59a6e58305090507387d412b3d@mail.gmail.com","subject":"Re: bogus merges","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-05T16:01:32Z","receivedAt":"2005-09-05T16:01:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 5 Sep 2005, Wayne Scott wrote:\n>\n> A recent commit in linux-2.6 looks like this:\n\nIt hopefully shouldn't happen any more with the improved and fixed\ngit-merge-base.\n\n> Author: Russell King <rmk@dyn-67.arm.linux.org.uk>\n> Date:   Wed Aug 31 10:12:14 2005 +0100\n\nI suspect rmk is using cogito-0.13, and that it still has the older \ngit-merge-base that can get confused by the date-ordering problem. And \nwhen git-merge-base gives the wrong result (not either of the commit \nobjects it was given as an argument), then \"git resolve\" will do the wrong \nthing.\n\nI just checked, and the _current_ git-merge-base definitely gives the \nright result:\n\n\tlinux$ git-merge-base -a \\\n\t\t6b39374a27eb4be7e9d82145ae270ba02ea90dc8 \\\n\t\t194d0710e1a7fe92dcf860ddd31fded8c3103b7a\n\nresults in\n\n\t194d0710e1a7fe92dcf860ddd31fded8c3103b7a\n\nie it correctly notices that the second commit is the parent of the first\none.\n\n> Really 'git commit' should detect problems like this automatically and\n> prevent them from getting in the tree.\n\nWell, that would depend on having the fixed git-merge-base in the first \nplace, which in turn would mean that such a commit wouldn't happen at all, \nso it's kind of circular. It's not worth fixing anywhere else, since once \nyou fix it in git-merge-base, it just becomes a non-issue.\n\nHopefully we'll have a new cogito release soon, and this particular bug\nwill be a thing of the past.\n\n\t\tLinus\n"},{"id":"8124","messageId":"59a6e58305090606082a23b048@mail.gmail.com","threadId":"1730","inReplyTo":"Pine.LNX.4.58.0509050853080.3568@evo.osdl.org","subject":"Re: bogus merges","fromName":"Wayne Scott","fromEmail":"wsc9tt@gmail.com","sentAt":"2005-09-06T13:08:57Z","receivedAt":"2005-09-06T13:08:57Z","isPatch":false,"sender":{"key":"wsc9tt@gmail.com","avatar":"https://gravatar.com/avatar/2418bf5fa7f1625a2b9dd049db4ab56110f561610421d6f2559f7c018ce53eb3?d=mp&s=160"},"body":"On 9/5/05, Linus Torvalds <torvalds@osdl.org> wrote:\n> > Really 'git commit' should detect problems like this automatically and\n> > prevent them from getting in the tree.\n> \n> Well, that would depend on having the fixed git-merge-base in the first\n> place, which in turn would mean that such a commit wouldn't happen at all,\n> so it's kind of circular. It's not worth fixing anywhere else, since once\n> you fix it in git-merge-base, it just becomes a non-issue.\n\nThis just error checking to prevent future bugs from getting committed\nto the tree.  These kinds of things are very hard to repair after the\nfact.\n\n-Wayne\n"},{"id":"8131","messageId":"Pine.LNX.4.63.0509061409180.23242@iabervon.org","threadId":"1730","inReplyTo":"Pine.LNX.4.58.0509050853080.3568@evo.osdl.org","subject":"Re: bogus merges","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-06T18:28:39Z","receivedAt":"2005-09-06T18:28:39Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 5 Sep 2005, Linus Torvalds wrote:\n\n> On Mon, 5 Sep 2005, Wayne Scott wrote:\n> >\n> > A recent commit in linux-2.6 looks like this:\n> \n> It hopefully shouldn't happen any more with the improved and fixed\n> git-merge-base.\n\nCouldn't it also happen if there's stale data in MERGE_HEAD when you \ncommit a normal patch? The description doesn't look like a merge at all, \nbut rather like a normal patch that inappropriately picked up an extra \nhead. I'd guess he tried to merge something, got a conflict, decided that \nhe didn't really want to do that anyway, switched to a different branch, \napplied a patch, and committed without noticing the note that he seemed to \nbe committing a merge.\n\nProbably the right thing is actually to clean up more when switching \ntasks, but it would probably also be worth checking that merges make sense \nas well.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"8284","messageId":"20050911112130.A7510@flint.arm.linux.org.uk","threadId":"1730","inReplyTo":"Pine.LNX.4.58.0509050853080.3568@evo.osdl.org","subject":"Re: bogus merges","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-09-11T10:21:30Z","receivedAt":"2005-09-11T10:21:30Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Mon, Sep 05, 2005 at 09:01:32AM -0700, Linus Torvalds wrote:\n> On Mon, 5 Sep 2005, Wayne Scott wrote:\n> > A recent commit in linux-2.6 looks like this:\n> \n> It hopefully shouldn't happen any more with the improved and fixed\n> git-merge-base.\n> \n> > Author: Russell King <rmk@dyn-67.arm.linux.org.uk>\n> > Date:   Wed Aug 31 10:12:14 2005 +0100\n> \n> I suspect rmk is using cogito-0.13\n\nCorrect, and rmk will probably be extremely nervous about upgrading when\n0.14 appears.\n\n-- \nRussell King\n"},{"id":"8285","messageId":"20050911120140.A8236@flint.arm.linux.org.uk","threadId":"1730","inReplyTo":"Pine.LNX.4.63.0509061409180.23242@iabervon.org","subject":"Re: bogus merges","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-09-11T11:01:40Z","receivedAt":"2005-09-11T11:01:40Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Tue, Sep 06, 2005 at 02:28:39PM -0400, Daniel Barkalow wrote:\n> On Mon, 5 Sep 2005, Linus Torvalds wrote:\n> > On Mon, 5 Sep 2005, Wayne Scott wrote:\n> > >\n> > > A recent commit in linux-2.6 looks like this:\n> > \n> > It hopefully shouldn't happen any more with the improved and fixed\n> > git-merge-base.\n> \n> Couldn't it also happen if there's stale data in MERGE_HEAD when you \n> commit a normal patch?\n\nI don't think Cogito has the idea of a MERGE_HEAD file.\n\n> The description doesn't look like a merge at all, \n> but rather like a normal patch that inappropriately picked up an extra \n> head. I'd guess he tried to merge something, got a conflict, decided that \n> he didn't really want to do that anyway, switched to a different branch, \n> applied a patch, and committed without noticing the note that he seemed to \n> be committing a merge.\n\n\"HE'd\" hadn't (please don't use the third person when you're talking about\nsomeone who is being copied on the thread, thanks.)  Look closer at the\ntwo heads (I've cut out the author info):\n\ncommit b129a8ccd53f74c43e4c83c8e0031a4990040830\ntree 4c40afd836be87166d6d014380262f1baa19694f\nparent 6b39374a27eb4be7e9d82145ae270ba02ea90dc8\nparent 194d0710e1a7fe92dcf860ddd31fded8c3103b7a\ncommitter Russell King <rmk+kernel@arm.linux.org.uk> Wed, 31 Aug 2005 10:12:14 +0100\n    [SERIAL] Clean up and fix tty transmission start/stoping\n\nwhich was apparantly (but not really) a merge between:\n\ncommit 6b39374a27eb4be7e9d82145ae270ba02ea90dc8\ntree 09933113cf28f253db1dd539463bdab741d67139\nparent 62c592edead3c3a045662595f7ade3c12f133373\nparent ed735ccbefaf7e5e3ef61418f7e209b8c59308a7\ncommitter Linus Torvalds <torvalds@g5.osdl.org> Tue, 30 Aug 2005 11:16:30 -0700\n    Merge refs/heads/upstream from master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\n\ncommit 194d0710e1a7fe92dcf860ddd31fded8c3103b7a\ntree da03b56fa4dee221c53af5770492d391f0d09459\nparent a68d2ebc1581a3aec57bd032651e013fa609f530\nparent 9bbd03758945858c9303f3258b418b94c4ffd735\ncommitter Linus Torvalds <torvalds@g5.osdl.org> Wed, 03 Aug 2005 13:09:43 -0700\n    Merge master.kernel.org:/home/rmk/linux-2.6-arm\n\nHowever, the serial tree (which commit b129a8ccd53f74c43e4c83c8e0031a4990040830\nwas created in) was last pulled in commit 975f957dc408925805dd8f5aa4217b7eeea2d005.\nFollowing the commit trail, you'll end up at commit\n6b39374a27eb4be7e9d82145ae270ba02ea90dc8 above.\n\ncommit 975f957dc408925805dd8f5aa4217b7eeea2d005\ntree 2198bb72323a016d93c7440c9240bac94a5c0016\nparent 2321fbd2b87539edc1fbfc2e186528a1ef93835f\nparent 661299d9d0437a0ff72240f3d60016ac3a361a6e\ncommitter Linus Torvalds <torvalds@g5.osdl.org> Mon, 29 Aug 2005 10:34:59 -0700\n    Merge HEAD from master.kernel.org:/home/rmk/linux-2.6-serial.git\n\nwhich was the result of the following merge between the head of the\nserial tree and Linus' tree:\n\ncommit 661299d9d0437a0ff72240f3d60016ac3a361a6e\ntree 765512576314fc3612b503f182b9ae4e60fcf849\nparent 05caac585f8abd6c0113856bc8858e3ef214d8a6\nparent 41c018b7ecb60b1c2c4d5dee0cd37d32a94c45af\ncommitter Russell King <rmk+kernel@arm.linux.org.uk> Thu, 28 Jul 2005 09:30:20 +0100\n    Merge with Linus' 2.6 tree\n\nThis was at the head of the serial tree at the time:\n\ncommit 05caac585f8abd6c0113856bc8858e3ef214d8a6\ntree ac9f8f2cc032281af09200da514257d120510906\nparent 241fc4367b3ca5d407b043599ed980304a70b91f\ncommitter Russell King <rmk+kernel@arm.linux.org.uk> Wed, 27 Jul 2005 11:41:18 +0100\n    [SERIAL] Convert parport_serial to use new 8250_pci interfaces\n\nSo, the question is, if the serial git tree was all happy in the\nmerge on 29th August (975f957dc408925805dd8f5aa4217b7eeea2d005)\nwhy did the next commit to that tree (being\nb129a8ccd53f74c43e4c83c8e0031a4990040830) go wrong when the\nprevious merge would have been a standard fast-forward operation.\n\nThere is _no_ reason why the serial tree would have been wound back\nto 3rd August.\n\n> Probably the right thing is actually to clean up more when switching \n> tasks, but it would probably also be worth checking that merges make sense \n> as well.\n\nYou might be right except for one small detail.  I don't \"switch tasks\"\nwith a single git tree.  I have a set of individual git trees, one per\n\"task\".  They always remain in a clean state due to the way I work:\n\n\t- update tree to Linus if Linus tree is a superset of the tree\n\t- apply changes in patch form to tree and commit each in turn\n\t- send linus a request to merge\n\nHowever, occasionally, I update the tree when Linus' tree is not a\nsuperset, as was the case in 661299d9d0437a0ff72240f3d60016ac3a361a6e\nabove.\n\n-- \nRussell King\n"},{"id":"8286","messageId":"20050911120611.B8236@flint.arm.linux.org.uk","threadId":"1730","inReplyTo":"59a6e58305090606082a23b048@mail.gmail.com","subject":"Re: bogus merges","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-09-11T11:06:11Z","receivedAt":"2005-09-11T11:06:11Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Tue, Sep 06, 2005 at 08:08:57AM -0500, Wayne Scott wrote:\n> On 9/5/05, Linus Torvalds <torvalds@osdl.org> wrote:\n> > > Really 'git commit' should detect problems like this automatically and\n> > > prevent them from getting in the tree.\n> > \n> > Well, that would depend on having the fixed git-merge-base in the first\n> > place, which in turn would mean that such a commit wouldn't happen at all,\n> > so it's kind of circular. It's not worth fixing anywhere else, since once\n> > you fix it in git-merge-base, it just becomes a non-issue.\n> \n> This just error checking to prevent future bugs from getting committed\n> to the tree.  These kinds of things are very hard to repair after the\n> fact.\n\nThey don't get repaired.\n\nThe real problem is that there needs to be a way for cogito to remain\nmore up to date with git, so that when problems are fixed in git they\ncan propagate into cogito faster.\n\nI'm not sure separating cogito from git is a good solution though -\nI've no real view on how stable the interface between those two bits\nare, but I'd hate for a git upgrade to break cogito in some subtle\nway.\n\n-- \nRussell King\n"},{"id":"8288","messageId":"46a038f905091104483cc01a11@mail.gmail.com","threadId":"1730","inReplyTo":"20050911112130.A7510@flint.arm.linux.org.uk","subject":"Re: bogus merges","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-09-11T11:48:10Z","receivedAt":"2005-09-11T11:48:10Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/11/05, Russell King <rmk@arm.linux.org.uk> wrote:\n> On Mon, Sep 05, 2005 at 09:01:32AM -0700, Linus Torvalds wrote:\n> > I suspect rmk is using cogito-0.13\n> \n> Correct, and rmk will probably be extremely nervous about upgrading when\n> 0.14 appears.\n\nWell, *actually* cogito-0.13 didn't include git-core, so we have to\nlook for the reasons elsewhere. Could be the leftover MERGE_HEAD\nDaniel mentions.\n\nRussel, can you confirm what git-core version you are/were running?\n\ncheers,.\n\n\nmartin\n"},{"id":"8292","messageId":"43244935.6060703@gmail.com","threadId":"1730","inReplyTo":"46a038f905091104483cc01a11@mail.gmail.com","subject":"Re: bogus merges","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-09-11T15:11:49Z","receivedAt":"2005-09-11T15:11:49Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Martin Langhoff wrote:\n> On 9/11/05, Russell King <rmk@arm.linux.org.uk> wrote:\n>>On Mon, Sep 05, 2005 at 09:01:32AM -0700, Linus Torvalds wrote:\n>>>I suspect rmk is using cogito-0.13\n>>Correct, and rmk will probably be extremely nervous about upgrading when\n>>0.14 appears.\n> \n> Well, *actually* cogito-0.13 didn't include git-core, so we have to\n> look for the reasons elsewhere. Could be the leftover MERGE_HEAD\n> Daniel mentions.\n> \n> Russel, can you confirm what git-core version you are/were running?\n\nRussel,\n\nHow are you updating your tree to Linus'? If you are rsyncing from \nkernel.org, you're probably getting a MERGE_HEAD with the rsync. A while \nago I got annoyed enough add the equivalent of:\n\n\trm -f ${LOCAL_REPOS}/.git/MERGE_HEAD\n\nto my (very stupid) git rsync script.\n"},{"id":"8304","messageId":"20050911190035.A24984@flint.arm.linux.org.uk","threadId":"1730","inReplyTo":"46a038f905091104483cc01a11@mail.gmail.com","subject":"Re: bogus merges","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-09-11T18:00:35Z","receivedAt":"2005-09-11T18:00:35Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sun, Sep 11, 2005 at 11:48:10PM +1200, Martin Langhoff wrote:\n> On 9/11/05, Russell King <rmk@arm.linux.org.uk> wrote:\n> > On Mon, Sep 05, 2005 at 09:01:32AM -0700, Linus Torvalds wrote:\n> > > I suspect rmk is using cogito-0.13\n> > \n> > Correct, and rmk will probably be extremely nervous about upgrading when\n> > 0.14 appears.\n> \n> Well, *actually* cogito-0.13 didn't include git-core, so we have to\n> look for the reasons elsewhere. Could be the leftover MERGE_HEAD\n> Daniel mentions.\n> \n> Russel, can you confirm what git-core version you are/were running?\n\nNope, because now that I look I'm actually using cogito 0.12.1\nnot 0.13 as I previously mentioned.  Oops.\n\n-- \nRussell King\n"},{"id":"8305","messageId":"Pine.LNX.4.63.0509111256300.23242@iabervon.org","threadId":"1730","inReplyTo":"20050911120140.A8236@flint.arm.linux.org.uk","subject":"Re: bogus merges","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-11T18:08:14Z","receivedAt":"2005-09-11T18:08:14Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 11 Sep 2005, Russell King wrote:\n\n> Look closer at the two heads (I've cut out the author info):\n> \n> commit b129a8ccd53f74c43e4c83c8e0031a4990040830\n> tree 4c40afd836be87166d6d014380262f1baa19694f\n> parent 6b39374a27eb4be7e9d82145ae270ba02ea90dc8\n> parent 194d0710e1a7fe92dcf860ddd31fded8c3103b7a\n> committer Russell King <rmk+kernel@arm.linux.org.uk> Wed, 31 Aug 2005 10:12:14 +0100\n>     [SERIAL] Clean up and fix tty transmission start/stoping\n> \n> which was apparantly (but not really) a merge between:\n> \n> commit 6b39374a27eb4be7e9d82145ae270ba02ea90dc8\n> tree 09933113cf28f253db1dd539463bdab741d67139\n> parent 62c592edead3c3a045662595f7ade3c12f133373\n> parent ed735ccbefaf7e5e3ef61418f7e209b8c59308a7\n> committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 30 Aug 2005 11:16:30 -0700\n>     Merge refs/heads/upstream from master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git\n> \n> commit 194d0710e1a7fe92dcf860ddd31fded8c3103b7a\n> tree da03b56fa4dee221c53af5770492d391f0d09459\n> parent a68d2ebc1581a3aec57bd032651e013fa609f530\n> parent 9bbd03758945858c9303f3258b418b94c4ffd735\n> committer Linus Torvalds <torvalds@g5.osdl.org> Wed, 03 Aug 2005 13:09:43 -0700\n>     Merge master.kernel.org:/home/rmk/linux-2.6-arm\n> \n> However, the serial tree (which commit b129a8ccd53f74c43e4c83c8e0031a4990040830\n> was created in) was last pulled in commit 975f957dc408925805dd8f5aa4217b7eeea2d005.\n> Following the commit trail, you'll end up at commit\n> 6b39374a27eb4be7e9d82145ae270ba02ea90dc8 above.\n> \n> commit 975f957dc408925805dd8f5aa4217b7eeea2d005\n> tree 2198bb72323a016d93c7440c9240bac94a5c0016\n> parent 2321fbd2b87539edc1fbfc2e186528a1ef93835f\n> parent 661299d9d0437a0ff72240f3d60016ac3a361a6e\n> committer Linus Torvalds <torvalds@g5.osdl.org> Mon, 29 Aug 2005 10:34:59 -0700\n>     Merge HEAD from master.kernel.org:/home/rmk/linux-2.6-serial.git\n> \n> which was the result of the following merge between the head of the\n> serial tree and Linus' tree:\n> \n> commit 661299d9d0437a0ff72240f3d60016ac3a361a6e\n> tree 765512576314fc3612b503f182b9ae4e60fcf849\n> parent 05caac585f8abd6c0113856bc8858e3ef214d8a6\n> parent 41c018b7ecb60b1c2c4d5dee0cd37d32a94c45af\n> committer Russell King <rmk+kernel@arm.linux.org.uk> Thu, 28 Jul 2005 09:30:20 +0100\n>     Merge with Linus' 2.6 tree\n> \n> This was at the head of the serial tree at the time:\n> \n> commit 05caac585f8abd6c0113856bc8858e3ef214d8a6\n> tree ac9f8f2cc032281af09200da514257d120510906\n> parent 241fc4367b3ca5d407b043599ed980304a70b91f\n> committer Russell King <rmk+kernel@arm.linux.org.uk> Wed, 27 Jul 2005 11:41:18 +0100\n>     [SERIAL] Convert parport_serial to use new 8250_pci interfaces\n> \n> You might be right except for one small detail.  I don't \"switch tasks\"\n> with a single git tree.\n\nI think I was right, but \"switching tasks\" has to be interpretted as \nswitching from a merge you don't care to complete to doing further \ndevelopment on that tree, and the \"switch\" is done by a fast-forward (to \nthe result of someone else completing the merge).\n\n>  I have a set of individual git trees, one per\n> \"task\".  They always remain in a clean state due to the way I work:\n> \n> \t- update tree to Linus if Linus tree is a superset of the tree\n> \t- apply changes in patch form to tree and commit each in turn\n> \t- send linus a request to merge\n> \n> However, occasionally, I update the tree when Linus' tree is not a\n> superset, as was the case in 661299d9d0437a0ff72240f3d60016ac3a361a6e\n> above.\n\nAh, okay. So I think the chain of events is:\n\n 28 Jul: You merge with Linus, when he hasn't pulled your tree. This goes \n         fine.\n 03 Aug: You pull from Linus again, but decide that you don't actually \n         care about tracking mainline in this tree so tightly. This leaves\n         194d... in .git/merging, because Cogito doesn't realize you're \n         not actually planning to complete the merge.\n 29 Aug: Linus pulls from you. This goes fine.\n 30 Aug: You update the tree again from Linus. This is a fast-forward and \n         goes fine, and doesn't touch .git/merging because it completes\n         the process without requiring input or a commit.\n 31 Aug: You make a different change and commit. This is the first time \n         you committed there since 03 Aug, and it thinks that you're still \n         merging your current head (now from 30 Aug) with 194d..., which \n         it marked down explicitly to track this when you started the \n         merge on the 3rd, and you don't get sufficient information to \n         realize that it's messed up.\n\nI think that the fundamental bug is that tree_timewrap() doesn't clear \n.git/merging, which means that it can still think you're doing a merge \nwhen you've started doing something else (such as doing further \ndevelopment after updating to someone else's merge of your tree).\n\nBut I still think that it would be worth checking for the parents in merge \ncommits making sense, because the fact that stale data is likely to be \nfrom abandoned operations on ancestors.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"8311","messageId":"20050911193628.B24984@flint.arm.linux.org.uk","threadId":"1730","inReplyTo":"43244935.6060703@gmail.com","subject":"Re: bogus merges","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-09-11T18:36:28Z","receivedAt":"2005-09-11T18:36:28Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sun, Sep 11, 2005 at 11:11:49AM -0400, A Large Angry SCM wrote:\n> Martin Langhoff wrote:\n> > On 9/11/05, Russell King <rmk@arm.linux.org.uk> wrote:\n> >>On Mon, Sep 05, 2005 at 09:01:32AM -0700, Linus Torvalds wrote:\n> >>>I suspect rmk is using cogito-0.13\n> >>Correct, and rmk will probably be extremely nervous about upgrading when\n> >>0.14 appears.\n> > \n> > Well, *actually* cogito-0.13 didn't include git-core, so we have to\n> > look for the reasons elsewhere. Could be the leftover MERGE_HEAD\n> > Daniel mentions.\n> > \n> > Russel, can you confirm what git-core version you are/were running?\n> \n> Russel,\n> \n> How are you updating your tree to Linus'? If you are rsyncing from \n> kernel.org, you're probably getting a MERGE_HEAD with the rsync. A while \n> ago I got annoyed enough add the equivalent of:\n> \n> \trm -f ${LOCAL_REPOS}/.git/MERGE_HEAD\n> \n> to my (very stupid) git rsync script.\n\nI think you can forget MERGE_HEAD.  Why?  I use cogito for pulling.\n\ncg-pull gets the head, and then rsyncs the objects found in the object\ndirectory.  It doesn't touch MERGE_HEAD.  None of the cogito scripts\nthat I have know anything about MERGE_HEAD itself.\n\n(Plus, it's actually a two stage pull - I have a cron-based cg-pull\ninto a master repository on one box, which I then cg-pull to the\ndevelopment box which is only powered when I'm working.)\n\n-- \nRussell King\n"},{"id":"8348","messageId":"20050912005807.GI15630@pasky.or.cz","threadId":"1730","inReplyTo":"Pine.LNX.4.63.0509111256300.23242@iabervon.org","subject":"Re: bogus merges","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-12T00:58:07Z","receivedAt":"2005-09-12T00:58:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Sep 11, 2005 at 08:08:14PM CEST, I got a letter\nwhere Daniel Barkalow <barkalow@iabervon.org> told me that...\n> I think that the fundamental bug is that tree_timewrap() doesn't clear \n> .git/merging, which means that it can still think you're doing a merge \n> when you've started doing something else (such as doing further \n> development after updating to someone else's merge of your tree).\n\nOh, nice catch. Thanks, fixed.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"}]}