{"thread":{"id":"89","subject":"Re: [1/5] Parsing code in revision.h","startedAt":"2005-04-17T20:06:18Z","lastAt":"2005-04-17T20:22:59Z","messageCount":2,"participants":["Daniel Barkalow","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"541","messageId":"Pine.LNX.4.58.0504171254500.7211@ppc970.osdl.org","threadId":"89","inReplyTo":"Pine.LNX.4.58.0504171253030.7211@ppc970.osdl.org","subject":"Re: [1/5] Parsing code in revision.h","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-17T20:06:18Z","receivedAt":"2005-04-17T20:06:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 17 Apr 2005, Linus Torvalds wrote:\n> \n> Yes. I'm not opposed to yours, I was just opposed to some of the things \n> around it you did, so I wrote mine as a kind of place-holder. I'll happily \n> take patches to turn it from a rally simple and stupid one into a more \n> polished version.\n\nBtw, before I forget - I did have another reason. I actually think that\nthe date is potentially a lot more important than \"how many parents deep\".\n\nIn particular, it's entirely possible that the top of my head might be a\nveru recent merge that merges with a small fix relative to a very old\nparent (making that old parent be just two hops away from the head), while\nthe thing I want to merge might also have that old parent (for similar\nreasons) as a relatively \"close\" parent from a pure link-counting\nstandpoint.\n\nThe reason I bring this up is that quite often people end up basing their\nwork on a specific release version, so a merge (especially in specialized\nareas) may thus bring such an old parent pretty close to the head, and it\ncan actually be quite possible (indeed probable) that such a parent ends\nup being a common parent.\n\nHowever, it can easily be a very _bad_ parent.\n\nIn ascii barfic:\n\n\t        ----------------------- patch ---------\n\t       /                                        \\\n\t      /                                          \\\n\t- old release -- ... lots of development .. -----HEAD\n\t     \\  \\\n\t      \\  \\\n\t       \\  ---------------------patch-- MERGE-HEAD      \n\t        \\                             /\n\t\t  .. lots of development ..  /\n\nit looks like \"old release\" is pretty close to both HEAD and MERGE-HEAD, \nright?\n\nBut that's just an artifact of the fact that they both had a trivial merge\nagainst some older code, and if the two \"lots of development\" things have\never done an earlier merge, there's quite possibly a _much_ better common\nparent there somewhere.\n\nI dunno.\n\n\t\tLinus\n"},{"id":"536","messageId":"Pine.LNX.4.21.0504171608070.30848-100000@iabervon.org","threadId":"89","inReplyTo":"Pine.LNX.4.58.0504171254500.7211@ppc970.osdl.org","subject":"Re: [1/5] Parsing code in revision.h","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-17T20:22:59Z","receivedAt":"2005-04-17T20:22:59Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 17 Apr 2005, Linus Torvalds wrote:\n\n> On Sun, 17 Apr 2005, Linus Torvalds wrote:\n> > \n> > Yes. I'm not opposed to yours, I was just opposed to some of the things \n> > around it you did, so I wrote mine as a kind of place-holder. I'll happily \n> > take patches to turn it from a rally simple and stupid one into a more \n> > polished version.\n> \n> Btw, before I forget - I did have another reason. I actually think that\n> the date is potentially a lot more important than \"how many parents deep\".\n> \n> In particular, it's entirely possible that the top of my head might be a\n> veru recent merge that merges with a small fix relative to a very old\n> parent (making that old parent be just two hops away from the head), while\n> the thing I want to merge might also have that old parent (for similar\n> reasons) as a relatively \"close\" parent from a pure link-counting\n> standpoint.\n> \n> The reason I bring this up is that quite often people end up basing their\n> work on a specific release version, so a merge (especially in specialized\n> areas) may thus bring such an old parent pretty close to the head, and it\n> can actually be quite possible (indeed probable) that such a parent ends\n> up being a common parent.\n> \n> However, it can easily be a very _bad_ parent.\n> \n> In ascii barfic:\n> \n> \t        ----------------------- patch ---------\n> \t       /                                        \\\n> \t      /                                          \\\n> \t- old release -- ... lots of development .. -----HEAD\n> \t     \\  \\                 /\n> \t      \\  \\               /\n> \t       \\  --------------/------patch-- MERGE-HEAD      \n> \t        \\              /              /\n> \t\t  .. lots of development ..  /\n\n(I added a merge line so there's another commit to discuss in the picture)\n\n> it looks like \"old release\" is pretty close to both HEAD and MERGE-HEAD, \n> right?\n> \n> But that's just an artifact of the fact that they both had a trivial merge\n> against some older code, and if the two \"lots of development\" things have\n> ever done an earlier merge, there's quite possibly a _much_ better common\n> parent there somewhere.\n> \n> I dunno.\n\nI think you're going to want multiple common ancestors being used in the\nmerge when this thing starts to happen; otherwise, you're going to have to\nfix up conflicts for \"patch\" for all the trees you pull. (Also, you're\nonly going to see a parent for patch (that is, the old revision as an\nancestor of the application of patch) if the trees are merging it in via\ngit, in which case you'll also see a commit for patch, which will have a\nrecent date. So you'd see \"just yesterday, we both merged a tiny \nchange; so that tree, which is very much like an ancient one, is more\nrecent that last weeks major merge\".\n\nI dunno either, but I hope we'll have 2+n-way-merge before there's a lot\nof complex history to deal with.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"}]}