{"thread":{"id":"1007","subject":"The coolest merge EVER!","startedAt":"2005-06-22T21:46:51Z","lastAt":"2005-06-24T19:22:28Z","messageCount":7,"participants":["Linus Torvalds","Jon Seymour","Jeff Garzik","Junio C Hamano","Matthias Urlichs","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5124","messageId":"Pine.LNX.4.58.0506221433540.2353@ppc970.osdl.org","threadId":"1007","inReplyTo":null,"subject":"The coolest merge EVER!","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-22T21:46:51Z","receivedAt":"2005-06-22T21:46:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOk, Junio had some cool octopus merges, but I just one-upped him.\n\nI just merged the \"gitk\" repository into git, and I did it as a real git\nmerge, which means that I actually retained all the original gitk\nrepository information intact. IOW, it's not a \"import the data\" thing,\nit's literally a merge of the two trees, and the result has two roots.\n\nNow, the advantage of this kind of merge is that Paul's original gitk\nrepository is totally unaffected by it, yet because I now have his history\n(and the exact same objects), the normal kind of git merge should work\nfine for me to continue to import Paul's work - we have the common parent\nneeded to resolve all differences.\n\nNow, I don't know how often this ends up being actually used in practice, \nbut at least in theory this is a totally generic thing, where you create a \n\"union\" of two git trees. I did the union merge manually, but in theory it \nshould be easy to automate, with simply something like\n\n\tgit fetch \n\tGIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD\n\tGIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u\n\tgit-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)\n\tcp .git/FETCH_HEAD .git/MERGE_HEAD\n\tgit commit\n\n(this is not exactly how I did it, but that's just because I'd never done\nthis before so I didn't think it through and I had some stupid extra steps\nin between that were unnecessary).\n\nOf course, in order for the union merge to work, the namespaces have to be\nfit on top of each other with no clashes, otherwise future merges will be \nquite painful. In the case of gitk, Paul's repository only tracked that \nsingle file, so that wasn't a problem.\n\nAnyway, you shouldn't notice anything new, except for the fact that \"gitk\" \nnow gets automatically included with the base git distribution. And the \ngit repository has two roots, but hey, git itself doesn't care.\n\n\t\t\tLinus\n"},{"id":"5136","messageId":"2cfc4032050622171258636771@mail.gmail.com","threadId":"1007","inReplyTo":"Pine.LNX.4.58.0506221433540.2353@ppc970.osdl.org","subject":"Re: The coolest merge EVER!","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-06-23T00:12:09Z","receivedAt":"2005-06-23T00:12:09Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 6/23/05, Linus Torvalds wrote:\n> \n> Ok, Junio had some cool octopus merges, but I just one-upped him.\n> \n> I just merged the \"gitk\" repository into git, and I did it as a real git\n> merge, which means that I actually retained all the original gitk\n> repository information intact. IOW, it's not a \"import the data\" thing,\n> it's literally a merge of the two trees, and the result has two roots.\n> \n> Now, the advantage of this kind of merge is that Paul's original gitk\n> repository is totally unaffected by it, yet because I now have his history\n> (and the exact same objects), the normal kind of git merge should work\n> fine for me to continue to import Paul's work - we have the common parent\n> needed to resolve all differences.\n> \n\nYou do realise what this means, don't you?\n\nThe Borg can now start accumulating software into one massive\nrepository of everything ever written and it will never forget -\nresistance will be futile.\n\nOf course, it may run out of disk space.\n\njon.\n"},{"id":"5138","messageId":"42BA0126.6080102@pobox.com","threadId":"1007","inReplyTo":"2cfc4032050622171258636771@mail.gmail.com","subject":"Re: The coolest merge EVER!","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-06-23T00:24:06Z","receivedAt":"2005-06-23T00:24:06Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Jon Seymour wrote:\n> You do realise what this means, don't you?\n> \n> The Borg can now start accumulating software into one massive\n> repository of everything ever written and it will never forget -\n> resistance will be futile.\n> \n> Of course, it may run out of disk space.\n\n\nThe kernel.org robots will melt before that happens :)\n\ngit has already increased the kernel.org file publish time over an hour. \n Hopefully inotify and an improved rsync will fix some of that.\n\n\tJeff\n\n\n"},{"id":"5204","messageId":"7v64w4d1n6.fsf@assigned-by-dhcp.cox.net","threadId":"1007","inReplyTo":"Pine.LNX.4.58.0506221433540.2353@ppc970.osdl.org","subject":"Re: The coolest merge EVER!","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-24T00:44:29Z","receivedAt":"2005-06-24T00:44:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> Now, the advantage of this kind of merge is that Paul's original gitk\nLT> repository is totally unaffected by it, yet because I now have his history\nLT> (and the exact same objects), the normal kind of git merge should work\nLT> fine for me to continue to import Paul's work - we have the common parent\nLT> needed to resolve all differences.\n\nThis clearly shows that you are in the \"project lead\" integrator\nmindset. Making it easy for you, the integrator, to pull\nchanges made in Paul's tree is what this \"coolest merge ever\" is\nall about, but I suspect there would be a massive additional\nsupport needed if you want to make it easy for Paul to pull\nchanges made to gitk in your tree.\n\nI am not saying I do not like it, however, to make it easy for\nPaul to pull changes made in your tree relevant only to gitk\npart, off the top of my head:\n\n - If a contributor to GIT wants to make a change to gitk that\n adds a new file that is used by gitk (say, some common tcl\n library thing to be included), we either need to feed them to\n Paul and get the changes propagate to you through him, or we\n need a way to mark that file somehow belonging to the\n development history rooted at gitk root, not GIT root.\n\n - Similarly, if a contributor to GIT wants to make a change to\n gitk file itself, feeding the change through Paul to you\n would lesson both your burden and Paul's.\n\n - Alternatively Paul can keep track of which files are relevant\n to gitk, slurp and merge commits while ignoring the files the\n gitk package does not care about. This one would involve\n interesting scripting somebody may want to tackle (hint,\n hint).\n\nLong time ago I had a discussion with somebody (I vaguely recall\nit was with Dan Barkalow but I am not sure) about this exact\nissue. He wanted to have a way to distinguish Cogito-only part\nand core GIT part in a Cogito source tree, and help developers\nfeed core changes to you and Cogito changes to Petr.\n\nBack then I dismissed that approach by saying that what is\nbroken was Cogito's source tree structure, which overlays two\nprojects that are theoretically separable and practically\nmanaged separately, and it is not worth supporting such a broken\nsource tree structure. Now you are making GIT source tree such\nan overlayed one.\n\n"},{"id":"5214","messageId":"pan.2005.06.24.11.54.51.598627@smurf.noris.de","threadId":"1007","inReplyTo":"7v64w4d1n6.fsf@assigned-by-dhcp.cox.net","subject":"Re: The coolest merge EVER!","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-06-24T11:54:52Z","receivedAt":"2005-06-24T11:54:52Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Junio C Hamano wrote:\n\n> I suspect there\n> would be a massive additional support needed if you want to make it easy\n> for Paul to pull changes made to gitk in your tree.\n\nI don't think that's possible; after all, the trees are now merged, so any\npull would fetch all of Linus' tree.\n\nPaul could do it as patches, or Linus could do it in a branch, or we could\nwrite something entirely different from git that happens to support\ncherrypicking. ;-)\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nWhat's so funny 'bout peace, love, and understanding?\n\n\n"},{"id":"5233","messageId":"Pine.LNX.4.21.0506241332150.30848-100000@iabervon.org","threadId":"1007","inReplyTo":"pan.2005.06.24.11.54.51.598627@smurf.noris.de","subject":"Re: The coolest merge EVER!","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-24T17:49:24Z","receivedAt":"2005-06-24T17:49:24Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 24 Jun 2005, Matthias Urlichs wrote:\n\n> Hi, Junio C Hamano wrote:\n> \n> > I suspect there\n> > would be a massive additional support needed if you want to make it easy\n> > for Paul to pull changes made to gitk in your tree.\n> \n> I don't think that's possible; after all, the trees are now merged, so any\n> pull would fetch all of Linus' tree.\n\nLinus could do:\n\n git-read-tree gitk-head\n git-update-cache gitk\n git-commit-tree `write-tree` -p gitk-head > gitk-patched-head\n git-read-tree HEAD\n git merge gitk-patched-head\n\n(or, better, use a separate index file for the gitk index)\n\n(to commit changes to the gitk script made in a git working directory)\n\nThe change I proposed earlier would be so that the system would know what\nwas going on and users wouldn't have to. Then someone who didn't know that\ngitk was (also) a separate project and just committed changes to it would\nstill generate gitk commits when appropriate.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5236","messageId":"Pine.LNX.4.58.0506241211100.11175@ppc970.osdl.org","threadId":"1007","inReplyTo":"pan.2005.06.24.11.54.51.598627@smurf.noris.de","subject":"Re: The coolest merge EVER!","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-24T19:22:28Z","receivedAt":"2005-06-24T19:22:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 24 Jun 2005, Matthias Urlichs wrote:\n\n> Hi, Junio C Hamano wrote:\n> \n> > I suspect there\n> > would be a massive additional support needed if you want to make it easy\n> > for Paul to pull changes made to gitk in your tree.\n> \n> I don't think that's possible; after all, the trees are now merged, so any\n> pull would fetch all of Linus' tree.\n\nNo no. \n\nA merge is a one-way thing. I merged Paul's tree, but Paul didn't merge \nmine. His is still independent, and you can still pull his tree without \ngetting the rest of git, and Paul can still continue to work on his tree \nas if I never merged it at all.\n\nNow, merging back isn't as easy: if any gitk changes get done in my \n\"union\" tree, Paul can't just pull those, becasue they now end up being \nlinked to the history of the unified thing, so when pulling, he'd now end \nup getting all of the regular git stuff too.\n\nWhich is probably acceptable, but Junio's point was that this is not a \nsymmetric setup: git is like a black hole that never lets any information \nescape, and once you've been sucked into a git archive, you end up not \nbeing able to separate it.\n\nOr rather, you _can_ separate out pieces of it, but now it's a matter of\ncherry-picking, not automatic merges. Of course, people want to be able to \ndo that anyway, and normally that will also merge back perfectly, so \nthere's no huge downside, except that we should make it fairly easy.\n\n\t\tLinus\n"}]}