{"thread":{"id":"2121","subject":"LCA2006 Git/Cogito tutorial","startedAt":"2005-10-17T00:48:09Z","lastAt":"2005-10-24T15:04:58Z","messageCount":14,"participants":["Martin Langhoff (CatalystIT)","Petr Baudis","Dmitry Torokhov","Junio C Hamano","Linus Torvalds","Fredrik Kuivinen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10169","messageId":"4352F4C9.1040703@catalyst.net.nz","threadId":"2121","inReplyTo":null,"subject":"LCA2006 Git/Cogito tutorial","fromName":"Martin Langhoff (CatalystIT)","fromEmail":"martin@catalyst.net.nz","sentAt":"2005-10-17T00:48:09Z","receivedAt":"2005-10-17T00:48:09Z","isPatch":false,"sender":{"key":"martin@laptop.org","avatar":null},"body":"Good news! Sounds like I will be hosting a Git/Cogito tutorial in the\nupcoming LCA2006 (Dunedin, NZ, Jan 25~28). Given that I do have some\nsignificant holes in my git knowledge (no, really!?) I'll be happy if\nother git hackers/users are present at LCA and willing to take part in\nthe tutorial.\n\nPetr Baudis hinted earlier that he might be coming, as did Linus (but\nhe was hoping for a sponsor, I'm not sure whether he'll be there or\nnot). Speak up if you'll be there!\n\nI'll post my slides and presentation plan beforehand to the list, to\navoid spreading misinfirmation/bad practices. They will probably be\nbased on a recent talk I gave @ Wellington Perl Mongers about\nswtiching to Git/Cogito:\n\n http://wellington.pm.org/archive/200510/git/\n\nThe feedback (from both non-cogito-users and actual cogito-users) was\nthat I made it sound too complicated, so the current plan is to focus\non the tutorial part, and leave \"under the hood\" parts for a rainy day\nor for an after tutorial in-the-corridor chat.\n\ncheers,\n\n\nmartin\nps: lately, about 30% of my emails to git@vger from gmail have been \ndropped on the floor. This is starting to get annoying, is anyone seeing \nsimilar issues?\n-- \n-----------------------------------------------------------------------\nMartin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington\nWEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St\nOFFICE: +64(4)916-7224 MOB: +64(21)364-017\n Make things as simple as possible, but no simpler - Einstein\n-----------------------------------------------------------------------\n"},{"id":"10392","messageId":"20051021005145.GB30889@pasky.or.cz","threadId":"2121","inReplyTo":"4352F4C9.1040703@catalyst.net.nz","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-21T00:51:45Z","receivedAt":"2005-10-21T00:51:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Oct 17, 2005 at 02:48:09AM CEST, I got a letter\nwhere \"Martin Langhoff (CatalystIT)\" told me that...\n> Petr Baudis hinted earlier that he might be coming, as did Linus (but\n> he was hoping for a sponsor, I'm not sure whether he'll be there or\n> not). Speak up if you'll be there!\n\nI'm sorry but I will not be there - it is too far away from my little\ncountry. :-(\n\n> I'll post my slides and presentation plan beforehand to the list, to\n> avoid spreading misinfirmation/bad practices. They will probably be\n> based on a recent talk I gave @ Wellington Perl Mongers about\n> swtiching to Git/Cogito:\n> \n> http://wellington.pm.org/archive/200510/git/\n\n(i) You might want to say \"cg-export\" instead of \"git-tar-tree\" (*shrug*)\n\n(ii) You say:\n\n\t- Very fast stupid merge\n\t ... and very smart, slow merges when stupid won't do\n\n What are you explicitly referring to? I don't think any kind of merge\nin GIT (unless something totally missed me) can be called \"very smart\".\nIf it's a three-way merge, it's never \"very smart\".\n\n(iii) I have only one major problem with your file:\n\n\temacs .gitignore\n\n This should be obviously:\n\n\tvim .gitignore\n\n;-)\n\n> ps: lately, about 30% of my emails to git@vger from gmail have been \n> dropped on the floor. This is starting to get annoying, is anyone seeing \n> similar issues?\n\nNot me. Perhaps I'm in some VIP class. :^)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10399","messageId":"200510202137.22311.dtor_core@ameritech.net","threadId":"2121","inReplyTo":"20051021005145.GB30889@pasky.or.cz","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Dmitry Torokhov","fromEmail":"dtor_core@ameritech.net","sentAt":"2005-10-21T02:37:21Z","receivedAt":"2005-10-21T02:37:21Z","isPatch":false,"sender":{"key":"dtor_core@ameritech.net","avatar":null},"body":"On Thursday 20 October 2005 19:51, Petr Baudis wrote:\n> (ii) You say:\n> \n>         - Very fast stupid merge\n>             ... and very smart, slow merges when stupid won't do\n> \n\nHe might be referring to manual merge which is indeed as smart as it gets :)\n\n-- \nDmitry\n"},{"id":"10401","messageId":"4358597A.6000306@catalyst.net.nz","threadId":"2121","inReplyTo":"200510202137.22311.dtor_core@ameritech.net","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Martin Langhoff (CatalystIT)","fromEmail":"martin@catalyst.net.nz","sentAt":"2005-10-21T02:59:06Z","receivedAt":"2005-10-21T02:59:06Z","isPatch":false,"sender":{"key":"martin@laptop.org","avatar":null},"body":"Dmitry Torokhov wrote:\n> On Thursday 20 October 2005 19:51, Petr Baudis wrote:\n> \n>>(ii) You say:\n>>\n>> - Very fast stupid merge\n>> ... and very smart, slow merges when stupid won't do\n> \n> He might be referring to manual merge which is indeed as smart as it gets :)\n\nAlmost. No, truly, I'm very impressed with git-merge.sh, which first \ndoes the simple git-read-tree -m, and it can then try several merger \nscripts to resolve the index. The \"smartest\" merge resolver we have \nfollows renames, but we could have language-specific and \nproject-specific resolvers, for instance.\n\nIf you combine the coolness of git-merge.sh with the fact that cg-merge \nright now is buggy[*]... I'm starting to rely on doing cg-fetch and \nrunning git-merge.sh by hand.\n\n* I just merged your latest fixes, knowing that they'd conflict on \ncg-fetch, but the merge didn't say a thing a bout cg-fetch, and only \ncomplained like this:\n\n MERGE ERROR: : Not handling case -> ->\n\nBut there were no conflicts at all in the tree! It seems to be that it's \ndropping the upstream changes it doesn't like.\n\ncheers,\n\n\nmartin\n-- \n-----------------------------------------------------------------------\nMartin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington\nWEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St\nOFFICE: +64(4)916-7224 MOB: +64(21)364-017\n Make things as simple as possible, but no simpler - Einstein\n-----------------------------------------------------------------------\n"},{"id":"10402","messageId":"43585A44.3050205@catalyst.net.nz","threadId":"2121","inReplyTo":"20051021005145.GB30889@pasky.or.cz","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Martin Langhoff (CatalystIT)","fromEmail":"martin@catalyst.net.nz","sentAt":"2005-10-21T03:02:28Z","receivedAt":"2005-10-21T03:02:28Z","isPatch":false,"sender":{"key":"martin@laptop.org","avatar":null},"body":"Petr Baudis wrote:\n\n> Dear diary, on Mon, Oct 17, 2005 at 02:48:09AM CEST, I got a letter\n> where \"Martin Langhoff (CatalystIT)\" told me that...\n> \n>>Petr Baudis hinted earlier that he might be coming, as did Linus (but\n>>he was hoping for a sponsor, I'm not sure whether he'll be there or\n>>not). Speak up if you'll be there!\n> \n> \n> I'm sorry but I will not be there - it is too far away from my little\n> country. :-(\n\nSad to hear that. I'll be soon in Europe, though, but not in CZ, \nunfortunately!\n\n> (i) You might want to say \"cg-export\" instead of \"git-tar-tree\" (*shrug*)\n\nYou're right! I hadn't seen that.\n\n> (ii) You say:\n> \n> \t- Very fast stupid merge\n> \t ... and very smart, slow merges when stupid won't do\n> \n> What are you explicitly referring to? I don't think any kind of merge\n> in GIT (unless something totally missed me) can be called \"very smart\".\n> If it's a three-way merge, it's never \"very smart\".\n\nSee latest developments on git-merge.sh -- we should really revamp \ncg-merge ;)\n\n> \tvim .gitignore\n\nThen it'd be a bug, not a feature ;)\n\n>>ps: lately, about 30% of my emails to git@vger from gmail have been \n>>dropped on the floor. This is starting to get annoying, is anyone seeing \n>>similar issues?\n> \n> \n> Not me. Perhaps I'm in some VIP class. :^)\n\nOh, I figured that out! Gmail's \"utf-8\" mode encodes everything in \nbase64. Awful sh*t. Reverted to ascii and life is good.\n\n\n\nmartin\n-- \n-----------------------------------------------------------------------\nMartin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington\nWEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St\nOFFICE: +64(4)916-7224 MOB: +64(21)364-017\n Make things as simple as possible, but no simpler - Einstein\n-----------------------------------------------------------------------\n"},{"id":"10420","messageId":"20051021091551.GE30889@pasky.or.cz","threadId":"2121","inReplyTo":"4358597A.6000306@catalyst.net.nz","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-21T09:15:51Z","receivedAt":"2005-10-21T09:15:51Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter\nwhere \"Martin Langhoff (CatalystIT)\" told me that...\n> Almost. No, truly, I'm very impressed with git-merge.sh, which first \n> does the simple git-read-tree -m, and it can then try several merger \n> scripts to resolve the index. The \"smartest\" merge resolver we have \n> follows renames, but we could have language-specific and \n> project-specific resolvers, for instance.\n\nYes, following renames is nice. But as long as it is three-way, it\nsuffers of inherent and rather nasty problems. Well, I'm watching the\nweave merge effort and plan to give it a try to port it to GIT when I\nhave some time.\n\n> If you combine the coolness of git-merge.sh with the fact that cg-merge \n> right now is buggy[*]... I'm starting to rely on doing cg-fetch and \n> running git-merge.sh by hand.\n> \n> * I just merged your latest fixes, knowing that they'd conflict on \n> cg-fetch, but the merge didn't say a thing a bout cg-fetch, and only \n> complained like this:\n> \n> MERGE ERROR: : Not handling case -> ->\n> \n> But there were no conflicts at all in the tree! It seems to be that it's \n> dropping the upstream changes it doesn't like.\n\nThere was a bug in argument parsing of cg-Xmergefile, already fixed now.\n\nWell, it's true that cg-Xmergefile still does not handle all merge\ncases, but it certainly will not be silent about it, at least. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10509","messageId":"7vu0f7u3xc.fsf@assigned-by-dhcp.cox.net","threadId":"2121","inReplyTo":"4358597A.6000306@catalyst.net.nz","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-24T00:58:07Z","receivedAt":"2005-10-24T00:58:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff (CatalystIT)\" writes:\n\n>>>(ii) You say:\n>>>\n>>> - Very fast stupid merge\n>>> ... and very smart, slow merges when stupid won't do\n>\n> Almost. No, truly, I'm very impressed with git-merge.sh, which first \n> does the simple git-read-tree -m, and it can then try several merger \n> scripts to resolve the index. The \"smartest\" merge resolver we have \n> follows renames, but we could have language-specific and \n> project-specific resolvers, for instance.\n\nI should not be saying this because I am the primary guilty\nparty, but you should not be so impressed.\n\nBeing able to specify which merge strategy to use is a useful\nthing, but I do not think being able to try more than one merge\nstrategies automatically, while it has some coolness value, is\nvery useful in practice.\n\nThe language-specific or project-specific part should be made\northogonal to merge strategy modules, which currently is not.\nThe primary thing Daniel's git-merge-resolve and Fredrik's\ngit-merge-recursive do is to figure out which paths can be\nresolved without merging the file contents, and which paths need\nto be resolved with file contents merge, and they use different\nstrategies to find which 3 variants of the contents to use for\nthat final merge.\n\nBut at the end of the day, merging the contents is done by\nrunning 'merge' in either case. This should be made either\ncustomizable, or we ship our standard one that can be extended\nto first run 'file' to see the file content type of what is\nbeing merged and run content specific merge program if there is\none.\n\nEven if we did that, we are still doing 3-way merge; git-merge\nframework may not mesh very well when we want to use something\nlike codeville merge which is not based on 3-way.\n"},{"id":"10511","messageId":"Pine.LNX.4.64.0510231804430.10477@g5.osdl.org","threadId":"2121","inReplyTo":"7vu0f7u3xc.fsf@assigned-by-dhcp.cox.net","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-24T01:35:43Z","receivedAt":"2005-10-24T01:35:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 23 Oct 2005, Junio C Hamano wrote:\n> \n> Even if we did that, we are still doing 3-way merge; git-merge\n> framework may not mesh very well when we want to use something\n> like codeville merge which is not based on 3-way.\n\nOh, the git merge is about a million times better than any silly weave \nmerge with extra BonusPoints and MagicCapitalizedNames.\n\nWhy? Because if you want to be slow and careful, you can always just \ncreate the weave after-the-fact and do a weave merge.\n\nAnd because well-behaved git merges as so fast, you can actually afford \nto so so.\n\nThere's nothing magic in a weave merge. It's just a trick. It doesn't need \nthe files to be in weave format beforehand, even though people seem to \nbelieve that file formats go together with it.\n\nIf somebody thinks a weave merge is wonderful and fixes everything, I have \nto rain on their parade. You still need to manually fix real conflicts up, \nand regardless, what kind of merge you do has _nothing_ to do with how you \nmaintain your files.\n\nIf you want to do a weave merge inside git, then the way to do that is to \njust create the weave on demand in the (rare) case where it's needed. We \nhave all the history. You might even just do a \"lazy weave\", which just \nstarts from the common parent, and ignores the history before that. \n\nMuch cheaper that way, and arguably nicer (others will argue that you want \nto take history into account, to decide about undo's etc. It's a matter of \ntaste). \n\nThe thing is, automatic merging isn't all _that_ important. The thing that \nmade BK wonderful at merging was that it had a wonderful tool for merging \nfor when there were real clashes, which is where the _really_ nasty cases \nare. The actual automatic merge wasn't necessarily anything magical.\n\n(Same went for applying diffs, btw. What made BK nice was \"renametool\". Of \ncourse, it was also what made me decide that tracking renames was the \nwrong thing to do in the first place, but if you make a CMS that does \nrenames, you'd better have a \"renametool\").\n\nAnd if you have a tool that helps you visually merge the _real_ clashes, \nit doesn't much matter if you are only half-way decent on the automatic \nones. They'll be so trivial that nobody cares.\n\nAnd it doesn't matter _how_ good your automatic merges are, there always \n_will_ be real clashes.\n\n[ Side note. Think about this for a while. Git did three-way merges \n pretty much since day one, but they only became _useful_ when we made it \n easy to see the merge conflicts and fix them up. That's a fundamental\n lesson right there: you don't have to be perfect, you have to make it \n easy for the user to fix up your imperfections. ]\n\nSo we should spend time on making it easy to see what the clash was, and \non tools to help resolve them. Some random merge-strategy-of-the-day is \njust bling-bling. \n\nThe reason people like merge strategies is that it's a nice area for some \nmental masturbation. You can create all these fancy examples. And then can \nignore the fact that most real merge problems end up being two people \nchanging the same code in different ways, that just need manual merging.\n\nDon't get me wrong - if somebody does a nice automated merge for git, it's \na good thing, but it's probably much more important to try to integrate \nsomething like xxdiff to a git workflow. And _that_ level is probably \nwhere you want to have special language-based coloring etc to further help \nthings out.\n\nSo keep your eyes on the ball. And \"automatic merge\" isn't it.\n\n\t\tLinus\n"},{"id":"10515","messageId":"7vy84jsn1o.fsf@assigned-by-dhcp.cox.net","threadId":"2121","inReplyTo":"Pine.LNX.4.64.0510231804430.10477@g5.osdl.org","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-24T01:48:03Z","receivedAt":"2005-10-24T01:48:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 23 Oct 2005, Junio C Hamano wrote:\n>> \n>> Even if we did that, we are still doing 3-way merge; git-merge\n>> framework may not mesh very well when we want to use something\n>> like codeville merge which is not based on 3-way.\n>\n> Oh, the git merge is about a million times better than any silly weave \n> merge with extra BonusPoints and MagicCapitalizedNames.\n>\n> Why? Because if you want to be slow and careful, you can always just \n> create the weave after-the-fact and do a weave merge.\n\nYes, I know that as the one who did the convention between\ngit-merge and merge strategy backends. The convention feeds two\n(or more) heads and the common ancestors git-merge already\nfigured out to the strategy backends.\n\nThe current callers only feed commits for \"$heads\" parameters,\nso the merge strategy backends are free to figure out the common\nancestor or even generate weave on the fly, but an unwritten\nrule was that strategy backends are expected to do something\nsensible even when the \"common ancestors\" and \"heads\" fed to\nthem are tree objects, which was my comment about 3-way was\nabout.\n"},{"id":"10518","messageId":"Pine.LNX.4.64.0510232020030.10477@g5.osdl.org","threadId":"2121","inReplyTo":"7vy84jsn1o.fsf@assigned-by-dhcp.cox.net","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-24T03:32:04Z","receivedAt":"2005-10-24T03:32:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 23 Oct 2005, Junio C Hamano wrote:\n> \n> The current callers only feed commits for \"$heads\" parameters,\n> so the merge strategy backends are free to figure out the common\n> ancestor or even generate weave on the fly, but an unwritten\n> rule was that strategy backends are expected to do something\n> sensible even when the \"common ancestors\" and \"heads\" fed to\n> them are tree objects, which was my comment about 3-way was\n> about.\n\nAhh. Yes, if you use raw trees, you're screwed - you can only ever do a \n3-way merge, since you can't try to figure out any history.\n\nI agree that the \"tree only\" case is interesting too - it's how you can \nmerge trees that may be related content-wise but don't share a history (eg \nthe same project maintained in separate source trees), and it's obviously \nhow you can merge totally unrelated projects (eg the gitk merge). At the \nsame time, I think that's a different kind of merge, in general. And we \ndefinitely shouldn't limit ourselves to things where such merges work.\n\nYes, tree-merges are wonderful, and they work really quite well, but I \ndefinitely want to keep the window open for merges that end up taking the \nfull history into account.\n\nI just don't think they are nearly as important as some people seem to \nthink. They should be a very special and unusual case, rather than \nsomething you expect to happen.\n\n\t\tLinus\n"},{"id":"10526","messageId":"20051024075431.GY30889@pasky.or.cz","threadId":"2121","inReplyTo":"Pine.LNX.4.64.0510231804430.10477@g5.osdl.org","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-24T07:54:31Z","receivedAt":"2005-10-24T07:54:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Oct 24, 2005 at 03:35:43AM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> Oh, the git merge is about a million times better than any silly weave \n> merge with extra BonusPoints and MagicCapitalizedNames.\n> \n> Why? Because if you want to be slow and careful, you can always just \n> create the weave after-the-fact and do a weave merge.\n\nThis doesn't make sense. Those silly weave merges only describe what to\ndo with the weave to do the merge, not how you got the weave in the\nfirst place.\n\n> So we should spend time on making it easy to see what the clash was, and \n> on tools to help resolve them. Some random merge-strategy-of-the-day is \n> just bling-bling. \n\nThe *primary* reason for new merge strategies is not reducing number\nof conflicts, but actually being able to force a conflict at places\nwhere it isn't crystal-clear what the resolution should be (but not\nconflicting where it should be clear), and especially at places where\nthe three-way merge *silently* gets it *wrong* without throwing any\nconflicts. And weren't it you who wanted a conservative merge strategy\nwhich wouldn't ever do that?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10527","messageId":"20051024083216.GA4397@c165.ib.student.liu.se","threadId":"2121","inReplyTo":"20051021091551.GE30889@pasky.or.cz","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2005-10-24T08:32:16Z","receivedAt":"2005-10-24T08:32:16Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Fri, Oct 21, 2005 at 11:15:51AM +0200, Petr Baudis wrote:\n> Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter\n> where \"Martin Langhoff (CatalystIT)\" told me that...\n> > Almost. No, truly, I'm very impressed with git-merge.sh, which first \n> > does the simple git-read-tree -m, and it can then try several merger \n> > scripts to resolve the index. The \"smartest\" merge resolver we have \n> > follows renames, but we could have language-specific and \n> > project-specific resolvers, for instance.\n> \n> Yes, following renames is nice. But as long as it is three-way, it\n> suffers of inherent and rather nasty problems. Well, I'm watching the\n> weave merge effort and plan to give it a try to port it to GIT when I\n> have some time.\n> \n\nWhich \"inherent and rather nasty problems\" are you referring to?\n\nI do not know of any merge case which is either cleanly merged to the\nwrong result by git-merge -s recursive, or cleanly merged when it\nshould be a conflict. (At least not if there aren't any directory\nrenames going on) If you know about such an example I would be very\ninterested in taking a look at it.\n\n- Fredrik\n"},{"id":"10530","messageId":"7v3bmrqmf6.fsf@assigned-by-dhcp.cox.net","threadId":"2121","inReplyTo":"20051024075431.GY30889@pasky.or.cz","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-24T09:44:29Z","receivedAt":"2005-10-24T09:44:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Mon, Oct 24, 2005 at 03:35:43AM CEST, I got a letter\n> where Linus Torvalds told me that...\n>> Oh, the git merge is about a million times better than any silly weave \n>> merge with extra BonusPoints and MagicCapitalizedNames.\n>> \n>> Why? Because if you want to be slow and careful, you can always just \n>> create the weave after-the-fact and do a weave merge.\n>\n> This doesn't make sense. Those silly weave merges only describe what to\n> do with the weave to do the merge, not how you got the weave in the\n> first place.\n\nTrue, but it should not be a problem that is made harder for you\nto solve by the fact that our repository is not based on weaves.\n\nUnless an weave-based SCM comes with an integrated editor that\nrecords line insertion and deletion user actions and forces\nusers to use that editor and nothing else, it also has to work\non two whole files (pre- and post-modification) in order to find\nthe matching lines and figure out the weave to record, on top of\nthe history before pre-modification image. I think you have the\nsame information as they have to create the weave after the fact\nfor each commit in that sense.\n"},{"id":"10535","messageId":"Pine.LNX.4.64.0510240743310.10477@g5.osdl.org","threadId":"2121","inReplyTo":"20051024075431.GY30889@pasky.or.cz","subject":"Re: LCA2006 Git/Cogito tutorial","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-24T15:04:58Z","receivedAt":"2005-10-24T15:04:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 24 Oct 2005, Petr Baudis wrote:\n> > \n> > Why? Because if you want to be slow and careful, you can always just \n> > create the weave after-the-fact and do a weave merge.\n> \n> This doesn't make sense. Those silly weave merges only describe what to\n> do with the weave to do the merge, not how you got the weave in the\n> first place.\n\nDo you think a weave is something magical that happens because the SCM \nkeeps the files as a weave?\n\nNo.\n\nThe weave is _not_ a \"a priori\" thing. The only primary thing is the \nhistory of the file contents. Even a weave-based system will always create \nthe weave out of the history - it just happens to also save the file in \nthat woven format.\n\nSo if you have the history, you can always just re-create the weave. It's \nnot rocket science. SCCS has been around for how many decades now?\n\nAnd the thing is, because git does NOT keep the files in weave format, it \ncan do the _normal_ case of a merge (same contents, never mind how they \nget there) much faster than anything else. The same-file merges are so \nunusual as to be unimportant - if it then takes a bit longer to handle \nthem because you want to use a weave, hey, you're still ahead.\n\n> The *primary* reason for new merge strategies is not reducing number\n> of conflicts, but actually being able to force a conflict at places\n> where it isn't crystal-clear what the resolution should be (but not\n> conflicting where it should be clear), and especially at places where\n> the three-way merge *silently* gets it *wrong* without throwing any\n> conflicts. And weren't it you who wanted a conservative merge strategy\n> which wouldn't ever do that?\n\nA three-way merge is plenty conservative for me.\n\nAny merge will always get some case wrong, exactly the same way any merge \nwill always get some that require fixing up, even if a human might say \n\"that's a stupid merge\". Two patches add the same thing to different \nplaces (an unsorted array of PCI ID's or whatever), and pretty much any \nmerge ever will silently \"mismerge\" it as far as a human is concerned. \nFrom a _technical_ point it was correct. In practice, it wasn't.\n\nSo when I say \"conservative\", I don't mean \"can never mis-merge\", because \nsuch a thing doesn't exist. No, \"conservative\" means that it seldom does \nit in practice, and that when it happens, you can at least understand why \nit happened.\n\nA simple strategy that makes people understand what happened is often much \nbetter than a more complex one. And you should never underestimate the \nimportance of peoples _expectations_. A three-way merge has a _huge_ \nadvantage in that absolutely tons of people are used to what it does: even \nwhen they don't necessarily \"understand\" the merge (they never cared), if \nthey've worked with CVS they've seen them before.\n\nDon't get me wrong - a weave merge is pretty damn conservative too. I'm \nnot down on weave merges, I just don't think that the difference is that \nhuge in practice - the difference between a three-way merge and a weave \nmerge is much smaller than the advantage of a good graphical tool and a \ngood workflow.\n\nThat's really my argument here: automated merges aren't the end-all. I \nrealize that a lot of SCM people think that three-way merges are old and \nboring and stupid, but the fact is, sometimes the old ways aren't the best \nways, but sometimes they are old just because they are good enough.\n\n\t\tLinus\n"}]}