{"thread":{"id":"334","subject":"Re: Merge with git-pasky II.","startedAt":"2005-04-26T18:55:50Z","lastAt":"2005-04-28T00:42:55Z","messageCount":15,"participants":["Bram Cohen","Linus Torvalds","Tom Lord","Daniel Barkalow","Diego Calleja","Fabian Franz","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1773","messageId":"Pine.LNX.4.44.0504261129500.4678-100000@wax.eds.org","threadId":"334","inReplyTo":null,"subject":"Re: Merge with git-pasky II.","fromName":"Bram Cohen","fromEmail":"bram@bitconjurer.org","sentAt":"2005-04-26T18:55:50Z","receivedAt":"2005-04-26T18:55:50Z","isPatch":false,"sender":{"key":"bram@bitconjurer.org","avatar":null},"body":"(my apologies for responding to old messages, I only just subscribed to\nthis list)\n\nLinus Torvalds wrote:\n> On Thu, 14 Apr 2005, Junio C Hamano wrote:\n> >\n> > You say \"merge these two trees\" above (I take it that you mean\n> > \"merge these two trees, taking account of this tree as their\n> > common ancestor\", so actually you are dealing with three trees),\n>\n> Yes. We're definitely talking three trees.\n\nThe LCA for different files might be at different points in the history.\nForcing them to all come from the same point produces very bad merges.\n\n> The fact is, we know how to make tree merges unambiguous, by just\n> totally ignoring the history between them.  Ie we know how to merge\n> data. I am pretty damn sure that _nobody_ knows how to merge \"data over\n> time\".\n\nYou're incorrect. Codeville does exactly that (history-aware merges which\ndo the right thing even in cases where 3-way merge can't)\n\n> > This however opens up another set of can of worms---it would\n> > involve not just three trees but all the trees in the commit\n> > chain in between.\n>\n> Exactly.  I seriously believe that the model is _broken_, simply because\n> it gets too complicated. At some point it boils down to \"keep it simple,\n> stupid\".\n\nThe Codeville merge algorithm is also quite simple, and is already\nimplemented and mature.\n\n> I've not even been convinved that renames are worth it. Nobody has\n> really given a good reason why.\n\nIf one person renames a file and another person modifies it then the\nchanges should be applied to the moved file.\n\nAlso, there's the directory rename case where one person moves a directory\nand another person adds a file to it, in which case the file should be\nmoved to the new directory location on merge. I gather than BK doesn't\nsupport this functionality, but Codeville and Monotone both do.\n\n>    I think you might as well interpret the whole object thing. Git\n> _does_ tell you how the objects changed, and I actually believe that a\n> diff that works in between objects (ie can show \"these lines moved from\n> this file X to tjhat file Y\") is a _hell_ of a lot more powerful than\n> \"rename\"  is.\n>\n>    So I'd seriously suggest that instead of worryign about renames,\n> people think about global diffs that aren't per-file. Git is good at\n> limiting the changes to a set of objects, and it should be entirely\n> possible to think of diffs as ways of moving lines _between_ objects and\n> not just within objects. It's quite common to move a function from one\n> file to another - certainly more so than renaming the whole file.\n>\n> In other words, I really believe renames are just a meaningless special\n> case of a much more interesting problem. Which is just one reason why\n> I'm not at all interested in bothering with them other than as a \"data\n> moved\" thing, which git already handles very well indeed.\n\nNothing, not eveny our beloved BitKeeper, has 'move lines between files'\nfunctionality, and for good reason.\n\nTo begin with, it's behaviorally extremely dubious. It would be not\nuncommon for the system to erroneously think that some files deleted from\none file were added to another, and then further changes down the line\nwould cause random unrelated files to get modified in unpredictable ways\nwhen merges happened.\n\nAlso, it presents a completely unsolved UI problem. If one person moves\nlines 5-15 of file A to file B, and another person concurrently rewrites\nlines 10-20 of file A, how on earth is that supposed to be presented to\nthe user? Codeville can support line moves *within* files just fine, but\ndoesn't do it because of the UI problem of presenting all the corner\ncases. Maybe someday somebody will do a PhD thesis on that topic and we'll\nadd it, but until then we're sticking with the basic functionality.\n\nHonestly, that you would think of doing whole-tree three-way merges and\neven consider moving lines between files shows that you haven't explored\nthe merge problem very deeply. This is a much harder problem than you\nthink it is, and one which has already been solved by other systems.\n\n-Bram\n\n"},{"id":"1781","messageId":"Pine.LNX.4.58.0504261256150.18901@ppc970.osdl.org","threadId":"334","inReplyTo":"Pine.LNX.4.44.0504261129500.4678-100000@wax.eds.org","subject":"Re: Merge with git-pasky II.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T19:58:18Z","receivedAt":"2005-04-26T19:58:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Apr 2005, Bram Cohen wrote:\n> \n> If one person renames a file and another person modifies it then the\n> changes should be applied to the moved file.\n\nBzzt. Wrong answer.\n\nThe _right_ answer is \"if one person moves a function, and another person \nmodifies the function, the changes should be applied to the moved \nfunction\".\n\nWhich is clearly a _much_ more common case than file renames.\n\nIn other words, if your algorithm doesn't handle the latter, then there is \nno point in handling the former either.\n\nAnd _if_ your algorithm handles the latter, then there's no point in \nhandling file renames specially, since the algorithm will have done that \ntoo, as a small part of it.\n\n\t\tLinus\n"},{"id":"1787","messageId":"200504262030.NAA21304@emf.net","threadId":"334","inReplyTo":"Pine.LNX.4.58.0504261256150.18901@ppc970.osdl.org","subject":"Re: Merge with git-pasky II.","fromName":"Tom Lord","fromEmail":"lord@emf.net","sentAt":"2005-04-26T20:30:04Z","receivedAt":"2005-04-26T20:30:04Z","isPatch":false,"sender":{"key":"lord@emf.net","avatar":null},"body":"\n\n   From: Linus Torvalds <torvalds@osdl.org>\n\n   On Tue, 26 Apr 2005, Bram Cohen wrote:\n   > \n   > If one person renames a file and another person modifies it then the\n   > changes should be applied to the moved file.\n\n   Bzzt. Wrong answer.\n\nYou're a little bit nuts, guy.\n\n-t\n"},{"id":"1790","messageId":"Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org","threadId":"334","inReplyTo":"Pine.LNX.4.58.0504261256150.18901@ppc970.osdl.org","subject":"Re: Merge with git-pasky II.","fromName":"Bram Cohen","fromEmail":"bram@bitconjurer.org","sentAt":"2005-04-26T20:31:31Z","receivedAt":"2005-04-26T20:31:31Z","isPatch":false,"sender":{"key":"bram@bitconjurer.org","avatar":null},"body":"Linus Torvalds wrote:\n\n> On Tue, 26 Apr 2005, Bram Cohen wrote:\n> >\n> > If one person renames a file and another person modifies it then the\n> > changes should be applied to the moved file.\n>\n> Bzzt. Wrong answer.\n\nI'm trying to be polite. You're not making that easy.\n\n> The _right_ answer is \"if one person moves a function, and another person\n> modifies the function, the changes should be applied to the moved\n> function\".\n\nNow that you're done being dismissive, could you either (a) rebut my quite\ndetailed explanation of exactly why that functionality is both a dubious\nidea and difficult to implement, or (b) admit that you have no plans\nwhatsoever for supporting any of this stuff? You can't have it both ways.\n\nWhat I'd really like to hear is some explanation of why git is\nreimplementing all of this stuff from scratch. Your implicit claims that\ngit will do more things than the other systems without having to reinvent\nall of their functionality first are, honestly, naive, ill-informed\narrogance.\n\nI'd like to reiterate that *nothing* out there supports moving lines\nbetween files, and further predict, with total confidence, that if git\ntries to support such functionality it will simply fail, either by giving\nup or creating a system which can behave horribly. Before you get all\ndismissive about this claim, please remember that I've spent years\nthinking about merge algorithms, and have actually designed and\nimplemented them, and have spoken at length with other people who have\ndone the same, while you've merely thought about them for a few weeks.\n\n> Which is clearly a _much_ more common case than file renames.\n\nEven if we pretend that these are comparable features, that's far from\nclearly true. Function moves within a file occur more frequently, but a\nfile rename moves *all* the functions within that file.\n\n> In other words, if your algorithm doesn't handle the latter, then there is\n> no point in handling the former either.\n\nIf someone offers you a dollar, no strings attached, do you turn them down\nbecause they didn't offer you ten?\n\n> And _if_ your algorithm handles the latter, then there's no point in\n> handling file renames specially, since the algorithm will have done that\n> too, as a small part of it.\n\nIn case these concepts got conflated, I'd like to point out that Codeville\nmerge both supports renames *and* does better than three-way merge can do\nat merging a single, non-renamed file. In most cases three-way and\ncodeville merge give the same answer, but there are some cases where there\nisn't a single appropriate LCA available, and in those cases codeville\nwill do the right thing while three-way can't.\n\n-Bram\n\n"},{"id":"1788","messageId":"Pine.LNX.4.21.0504261607310.30848-100000@iabervon.org","threadId":"334","inReplyTo":"Pine.LNX.4.58.0504261256150.18901@ppc970.osdl.org","subject":"Re: Merge with git-pasky II.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-26T20:31:49Z","receivedAt":"2005-04-26T20:31:49Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 26 Apr 2005, Linus Torvalds wrote:\n\n> \n> \n> On Tue, 26 Apr 2005, Bram Cohen wrote:\n> > \n> > If one person renames a file and another person modifies it then the\n> > changes should be applied to the moved file.\n> \n> Bzzt. Wrong answer.\n> \n> The _right_ answer is \"if one person moves a function, and another person \n> modifies the function, the changes should be applied to the moved \n> function\".\n\nI'd even go so far as to say that we need to have the user sign off on\nthis. The modification is reasonably likely to not work in the new\nlocation, due to use of statics that aren't available or something of the\nsort.\n\nI suspect that we want to report a conflict in the new location between\nthe old version and the new version, and let the person merging check\nwhether the change is okay. That is, both sides modified the same section\nat the same time: one side modified its content, while the other modified\nits location. We can give a good suggestion, but we need a final ruling.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"1793","messageId":"200504262039.NAA21459@emf.net","threadId":"334","inReplyTo":"Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org","subject":"Re: Merge with git-pasky II.","fromName":"Tom Lord","fromEmail":"lord@emf.net","sentAt":"2005-04-26T20:39:54Z","receivedAt":"2005-04-26T20:39:54Z","isPatch":false,"sender":{"key":"lord@emf.net","avatar":null},"body":"\n  > What I'd really like to hear is some explanation of why git is\n  > reimplementing all of this stuff from scratch.\n\nWhatever Linus' reasons, it's not a bad exercise and it does help\nrobustify the kernel project to roll its own.  Not that he seems to be\ndoing *this* part especially well or anything, but that doesn't matter\nfrom the perspective of the good reasons to do it.\n\nIt doesn't matter much -- get stuff into git and people can layer on\nthat pretty gently.  The low layers of git are a common idea but\ncontext and Linus' nifty code make this instance of the idea a bit\nof a gem.\n\n\n\n  > please remember that I've spent years\n  > thinking about merge algorithms\n\nI'm surprised we haven't met sooner.  If we did and I forgot, sorry.\n\n-t\n"},{"id":"1795","messageId":"200504262044.NAA21518@emf.net","threadId":"334","inReplyTo":"Pine.LNX.4.21.0504261607310.30848-100000@iabervon.org","subject":"Re: Merge with git-pasky II.","fromName":"Tom Lord","fromEmail":"lord@emf.net","sentAt":"2005-04-26T20:44:02Z","receivedAt":"2005-04-26T20:44:02Z","isPatch":false,"sender":{"key":"lord@emf.net","avatar":null},"body":"\n\n"},{"id":"1797","messageId":"Pine.LNX.4.58.0504261347520.18901@ppc970.osdl.org","threadId":"334","inReplyTo":"Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org","subject":"Re: Merge with git-pasky II.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T20:58:44Z","receivedAt":"2005-04-26T20:58:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Apr 2005, Bram Cohen wrote:\n> \n> Now that you're done being dismissive, could you either (a) rebut my quite\n> detailed explanation of exactly why that functionality is both a dubious\n> idea and difficult to implement, or (b) admit that you have no plans\n> whatsoever for supporting any of this stuff? You can't have it both ways.\n\nI'm absolutely not going to do it myself, you're right about that.\n\nI just don't like your notion that you should support the 5% problem with\nugly hacks, and then you dismiss the 95% problem with \"nothing else does \nit either\".\n\nIn other words, we're already merging manually for the 95%. Why do you \nthink the 5% is so important?\n\n> What I'd really like to hear is some explanation of why git is\n> reimplementing all of this stuff from scratch.\n\nGit does in ~5000 lines and two weeks of work what _I_ think is the right \nthing to do. You're welcome to disagree, but the fact is, people have \nwhined and moaned about my use of BK FOR THREE YEARS without showing me \nany better alternatives.\n\nSo why are you complaining now, when I implement my own version in two\nweeks?\n\n> If someone offers you a dollar, no strings attached, do you turn them down\n> because they didn't offer you ten?\n\n\"no strings attached\"?\n\nThere are lots of strings attached to the \"follow renames\" thing. There's \n30 _years_ of strings attached, and they result in people not looking at \nthe _interesting_ problem.\n\nExactly because people follow renames, they think that they have the \nhistory of the code, but then they ignore the fact that they don't - \nbecause it doesn't follow merging of code or splitting of code.\n\nIn other words, it's sometimes better to know that you don't know the\nanswer, than it is to _think_ that you know the answer.\n\n> In case these concepts got conflated, I'd like to point out that Codeville\n> merge both supports renames *and* does better than three-way merge can do\n> at merging a single, non-renamed file.\n\nAnd I'd like to point out (again) that git doesn't actually care what \nmerge strategy the user uses. \n\nMe _personally_, I want to have something that is very repeatable and\nnon-clever. Something I understand _or_ tells me that it can't do it. And\nquite frankly, merging single-file history _without_ taking all the other\nfiles' history into account makes me go \"ugh\".\n\nThat's why I like the \"we do _not_ look for 'nearer' parents on a per-file\nbasis\", which is what this discussion started with, afaik. I think the \nonly original source that makes sense is the least common parent for the \nwhole _project_, exactly because other files have done things that may or \nmay not depend on the history of the file you're merging.\n\nI (and thus git) really takes a \"whole project\" approach. \n\n\t\t\tLinus\n"},{"id":"1801","messageId":"Pine.LNX.4.58.0504261408460.18901@ppc970.osdl.org","threadId":"334","inReplyTo":"Pine.LNX.4.58.0504261347520.18901@ppc970.osdl.org","subject":"Re: Merge with git-pasky II.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T21:25:02Z","receivedAt":"2005-04-26T21:25:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Apr 2005, Linus Torvalds wrote:\n> \n> > What I'd really like to hear is some explanation of why git is\n> > reimplementing all of this stuff from scratch.\n> \n> Git does in ~5000 lines and two weeks of work what _I_ think is the right \n> thing to do. You're welcome to disagree, but the fact is, people have \n> whined and moaned about my use of BK FOR THREE YEARS without showing me \n> any better alternatives.\n\nBtw, I've also been pretty disgusted by SCM's apparently generally caring \nabout stuff that is totally not relevant.\n\nFor example, it seems like most SCM people think that merging is about\ngetting the end result of two conflicting patches right.\n\nIn my opinion, that's the _least_ important part of a merge. Maybe the \nkernel is very unusual in this, but basically true _conflicts_ are not \nonly rare, but they tend to be things you want a human to look at \nregardless.\n\nThe important part of a merge is not how it handles conflicts (which need\nto be verified by a human anyway if they are at all interesting), but that\nit should meld the history together right so that you have a new solid\nbase for future merges.\n\nIn other words, the important part is the _trivial_ part: the naming of\nthe parents, and keeping track of their relationship. Not the clashes.\n\nFor example, CVS gets this part totally wrong. Sure, it can merge the \ncontents, but it totally ignores the important part, so once you've done a \nmerge, you're pretty much up shit creek wrt any subsequent merges in any \nother direction. All the other CVS problems pale in comparison. Renames? \nJust a detail.\n\nAnd it looks like 99% of SCM people seem to think that the solution to \nthat is to be more clever about content merges. Which misses the point \nentirely.\n\nDon't get me wrong: content merges are nice, but they are _gravy_. They\nare not important. You can do them manually if you have to. What's\nimportant is that once you _have_ done them (manually or automatically),\nthe system had better be able to go on, knowing that they've been done.\n\n\t\tLinus\n"},{"id":"1803","messageId":"20050426232624.4a68a720.diegocg@gmail.com","threadId":"334","inReplyTo":"Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org","subject":"Re: Merge with git-pasky II.","fromName":"Diego Calleja","fromEmail":"diegocg@gmail.com","sentAt":"2005-04-26T21:26:24Z","receivedAt":"2005-04-26T21:26:24Z","isPatch":false,"sender":{"key":"diegocg@gmail.com","avatar":null},"body":"El Tue, 26 Apr 2005 13:31:31 -0700 (PDT),\nBram Cohen <bram@bitconjurer.org> escribió:\n\n> Even if we pretend that these are comparable features, that's far from\n> clearly true. Function moves within a file occur more frequently, but a\n> file rename moves *all* the functions within that file.\n\nRenaming or moving files is _so_ rare and unusual that even not implementing\nit (like CVS) is hardly a big issue. Even in the linux kernel people moved subsystems\naround - OSS went from drivers/sound to /sound/oss in 2.6, and a USB subdirectory\nmoved too, I think.\n\nThe patch got bigger. People wasted 30 seconds more of their life because the .gz\nfile was bigger - who cares? If it's something it's going to happen every 5 years,\nI'd rather move them like CVS does rather than wasting a single second\nimplementing file renaming/moving...\n\nIf something so uncommon like file renaming has been implemented, I don't see\nwhy people shouldn't implement something really useful like the thing linus\nproposes, in fact it doesn't looks like a bad idea at all (and you'd get\nfile renaming for free, too). Perhaps it would be hard to implement and get\nright, but at least it would be _useful_.\n"},{"id":"1804","messageId":"Pine.LNX.4.44.0504261400570.4678-100000@wax.eds.org","threadId":"334","inReplyTo":"Pine.LNX.4.58.0504261347520.18901@ppc970.osdl.org","subject":"Re: Merge with git-pasky II.","fromName":"Bram Cohen","fromEmail":"bram@bitconjurer.org","sentAt":"2005-04-26T21:28:34Z","receivedAt":"2005-04-26T21:28:34Z","isPatch":false,"sender":{"key":"bram@bitconjurer.org","avatar":null},"body":"Linus Torvalds wrote:\n\n> On Tue, 26 Apr 2005, Bram Cohen wrote:\n> >\n> > Now that you're done being dismissive, could you either (a) rebut my quite\n> > detailed explanation of exactly why that functionality is both a dubious\n> > idea and difficult to implement, or (b) admit that you have no plans\n> > whatsoever for supporting any of this stuff? You can't have it both ways.\n>\n> I'm absolutely not going to do it myself, you're right about that.\n\nNow you're just being an ass. I stated, flatly, that what you're proposing\nto have done (by you or whoever, for feasibility it doesn't matter which)\nis not going to happen due to just plain difficulty. You obviously\ndisagree with me, but rather than coming out and saying so you're\npretending I didn't make that statement.\n\n> > What I'd really like to hear is some explanation of why git is\n> > reimplementing all of this stuff from scratch.\n>\n> Git does in ~5000 lines and two weeks of work what _I_ think is the right\n> thing to do.\n\nSo you think that a system which supports snapshots and history but has no\nmerging functionality whatsoever is the right thing? I'm asking this\nseriously. You have a magic --make-somebody-else-do-merge command, but for\neverybody else the current state of things is workable as a stopgap\nmeasure (the original plan) but very painful for anything more.\n\nCodeville is comparable in terms of number of lines of code to Git, by the\nway.\n\n> You're welcome to disagree, but the fact is, people have whined and\n> moaned about my use of BK FOR THREE YEARS without showing me any better\n> alternatives.\n\nYou were happy with BitKeeper, so why should we? Monotone and Codeville\nare only just about now really mature, and you aren't exactly known as a\nmodel customer.\n\n> So why are you complaining now, when I implement my own version in two\n> weeks?\n\nI'm trying to tell you that the amount of time between now and when a\nsystem as nice as BitKeeper is in use by the kernel can be dramatically\nreduced by either using an existing system verbatim or basing new efforts\non one.\n\nIf you think that git as it exists right now is at all comparable to\nMonotone or Codeville you're completely delusional.\n\n> > In case these concepts got conflated, I'd like to point out that Codeville\n> > merge both supports renames *and* does better than three-way merge can do\n> > at merging a single, non-renamed file.\n>\n> And I'd like to point out (again) that git doesn't actually care what\n> merge strategy the user uses.\n>\n> Me _personally_, I want to have something that is very repeatable and\n> non-clever. Something I understand _or_ tells me that it can't do it. And\n> quite frankly, merging single-file history _without_ taking all the other\n> files' history into account makes me go \"ugh\".\n\nNow you've just gone off the deep end. This is an apples-to-apples\ncomparison. Please accept one of thee following two statements:\n\n(a) Git doesn't do merging, and none of the related new tools around it do\nmerging.\n\n(b) Codeville merge (sans rename functionality) would be superior for the\nmerging which will be done.\n\n-Bram\n\n"},{"id":"1807","messageId":"200504262336.02583.FabianFranz@gmx.de","threadId":"334","inReplyTo":"Pine.LNX.4.44.0504261400570.4678-100000@wax.eds.org","subject":"Re: Merge with git-pasky II.","fromName":"Fabian Franz","fromEmail":"fabianfranz@gmx.de","sentAt":"2005-04-26T21:36:27Z","receivedAt":"2005-04-26T21:36:27Z","isPatch":false,"sender":{"key":"fabianfranz@gmx.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAm Dienstag, 26. April 2005 23:28 schrieb Bram Cohen:\n> Now you've just gone off the deep end. This is an apples-to-apples\n> comparison. Please accept one of thee following two statements:\n>\n> (a) Git doesn't do merging, and none of the related new tools around it do\n> merging.\n>\n> (b) Codeville merge (sans rename functionality) would be superior for the\n> merging which will be done.\n\nI have one very humble question:\n\nWhy don't you write and contribute some code for git to do good merging?\n\nThis would resolve all your problems.\n\nI think the \"magic-merge\" command is quite exchangable and if your way works\ngood and is compatible, then people will automatically start using that.\n\ncu\n\nFabian\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.4 (GNU/Linux)\n\niD8DBQFCbrRdI0lSH7CXz7MRAkS4AJ9JEka71M0Zc6cizXhrYpHiKHhL0gCcD/3Q\nj+UnPU/cXafGjGG6Bt9mZE8=\n=IYk0\n-----END PGP SIGNATURE-----\n\n"},{"id":"1812","messageId":"Pine.LNX.4.58.0504261522340.18901@ppc970.osdl.org","threadId":"334","inReplyTo":"Pine.LNX.4.44.0504261400570.4678-100000@wax.eds.org","subject":"Re: Merge with git-pasky II.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T22:25:58Z","receivedAt":"2005-04-26T22:25:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Apr 2005, Bram Cohen wrote:\n> \n> So you think that a system which supports snapshots and history but has no\n> merging functionality whatsoever is the right thing?\n\nYou haven't looked at git, have you?\n\nGit already merges better than _any_ open-source SCM out there. It just \ndoes it so effortlessly that you didn't even realize it does that.\n\nToday I've done four (count them) fully automated merges on the kernel\ntree: serial, networking, usb and arm.\n\nAnd they took a fraction of a second (plus the download of the new\nobjects, which is the real cost).\n\nThis is something that SVN _still_ cannot do, for example. \n\n\t\tLinus\n"},{"id":"1816","messageId":"Pine.LNX.4.58.0504261528110.18901@ppc970.osdl.org","threadId":"334","inReplyTo":"200504262336.02583.FabianFranz@gmx.de","subject":"Re: Merge with git-pasky II.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T22:30:06Z","receivedAt":"2005-04-26T22:30:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Apr 2005, Fabian Franz wrote:\n> \n> Am Dienstag, 26. April 2005 23:28 schrieb Bram Cohen:\n> > Now you've just gone off the deep end. This is an apples-to-apples\n> > comparison. Please accept one of thee following two statements:\n> >\n> > (a) Git doesn't do merging, and none of the related new tools around it do\n> > merging.\n> >\n> > (b) Codeville merge (sans rename functionality) would be superior for the\n> > merging which will be done.\n> \n> I have one very humble question:\n> \n> Why don't you write and contribute some code for git to do good merging?\n\nDon't bother. Bram doesn't know what he's talking about. \n\n\t\tLinus\n"},{"id":"1950","messageId":"20050428004254.GX22956@pasky.ji.cz","threadId":"334","inReplyTo":"Pine.LNX.4.58.0504261522340.18901@ppc970.osdl.org","subject":"Re: Merge with git-pasky II.","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-28T00:42:55Z","receivedAt":"2005-04-28T00:42:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Apr 27, 2005 at 12:25:58AM CEST, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> On Tue, 26 Apr 2005, Bram Cohen wrote:\n> > \n> > So you think that a system which supports snapshots and history but has no\n> > merging functionality whatsoever is the right thing?\n> \n> You haven't looked at git, have you?\n> \n> Git already merges better than _any_ open-source SCM out there. It just \n> does it so effortlessly that you didn't even realize it does that.\n\nDid you (or any other kernel developer reading this) actually try the\nCodeville merge? (I admit I didn't get time to do anything real with it\nyet.) SCM people keep praising it (as basically the best (at least\nopen-source) merge out there), so it would be interesting to compare\nthat with the actual real-world experience with it on the kernel.\n\n> Today I've done four (count them) fully automated merges on the kernel\n> tree: serial, networking, usb and arm.\n> \n> And they took a fraction of a second (plus the download of the new\n> objects, which is the real cost).\n> \n> This is something that SVN _still_ cannot do, for example. \n\nI think SVN is just irrelevant here - it is a completely different\nleague. The contenders here are probably Codeville, Monotone and perhaps\nGNU Arch offsprings.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"}]}