{"thread":{"id":"14777","subject":"Git vs Monotone","startedAt":"2008-07-31T18:13:59Z","lastAt":"2008-08-23T19:23:06Z","messageCount":33,"participants":["Sverre Rabbelier","Stephen R. van den Berg","Petr Baudis","Jeff King","Craig L. Ching","Linus Torvalds","Theodore Tso","Shawn O. Pearce","Junio C Hamano","Blum, Robert","Björn Steinbrink","Sean Estabrooks","Avery Pennarun","Martin Langhoff","Dmitry Torokhov","David Kastrup","Daniel Barkalow","Robin Rosenberg","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"85788","messageId":"bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com","threadId":"14777","inReplyTo":null,"subject":"Git vs Monotone","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-31T18:13:59Z","receivedAt":"2008-07-31T18:13:59Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"Heya,\n\nI just read this blog post [0] in which one of the Pidgin devs sheds\nhis light on their 'tool choice'. In the post he mentions the\nfollowing figures:\n\n\"I don't mind the database, myself. I have 11 working copies\n(checkouts) from my single pidgin database (8 distinct branches, plus\nduplicates of the last three branches I worked on or tested with).\nEach clean checkout (that is, a checkout prior to running autogen.sh\nand building) is approximately 61 MB. If this were SVN, each working\ncopy would be approximately 122 MB due to svn keeping a pristine copy\nof every file to facilitate 'svn diff' and 'svn revert' without\nneeding to contact the server the working copy was pulled from. Now,\nlet's add that up. For SVN, I would have 11 times 122 MB, or 1342 MB,\njust in working copies. For monotone, I have 11 times 61 MB for the\nworking copies (671 MB), plus 229 MB for the database, for a grand\ntotal of 900 MB. For me, this is an excellent bargain, as I save 442\nMB of disk space thanks to the monotone model. For another compelling\ncomparison that's sure to ruffle a few feathers, let's compare to git.\nIf I clone the git mirror of our monotone repository, I find a\ncheckout size of 148 MB after git-repack--running git-gc also\nincreased the size by 2 MB, but I'll stick with the initial checkout\nsize for fairness. If I multiply this by my 11 checkouts, I will have\n1628 MB. This is even more compelling for me, as I now save 728 MB of\ndisk space with monotone.\"\n\nI'm in the process of cloning the repo myself, and will check if doing\na more aggressive (high --window and --depth values) repack will get\nus below that 148, but I'm thinking it's just that big a repo. Anyway,\nit seems git is getting screwed over in this post because he is not\ntaking advantage of git's object-database-sharing capabilities. Am i\nright in thinking that with git-new-workdir we would end up at\n61*11+148 = 819MB? (Which would actually put us below monotone by\n80MB.) Not that I care much whether monotone or git is smaller in disk\nsize, I'm just curious if we indeed offer this capability? Perhaps\nsomeone with more knowledge of git-new-workdir could shed a light?\n\n[0] http://theflamingbanker.blogspot.com/2008/07/holy-war-of-tool-choice.html\n\n--\nCheers,\n\nSverre Rabbelier\n"},{"id":"85792","messageId":"20080731183317.GA31085@cuci.nl","threadId":"14777","inReplyTo":"bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com","subject":"Re: Git vs Monotone","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-07-31T18:33:17Z","receivedAt":"2008-07-31T18:33:17Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Sverre Rabbelier wrote:\n>If I clone the git mirror of our monotone repository, I find a\n>checkout size of 148 MB after git-repack--running git-gc also\n>increased the size by 2 MB, but I'll stick with the initial checkout\n>size for fairness. If I multiply this by my 11 checkouts, I will have\n>1628 MB. This is even more compelling for me, as I now save 728 MB of\n>disk space with monotone.\"\n\nYou have at least two options to reduce diskspace:\na. Clone once from remote, then clone from that clone, it should\n hardlink the larger packfiles to the initial clone and therefore not\n cost you a lot.\nb. Clone once from remote, and create 11 branches inside the new cloned\n repo. Switch branches while doing development.\n\nMost git users pick b. It's easier to work with. Having 11 unpacked\nrepos means that all the object files in those trees are almost up to\ndate, but it adds to the complexity of comparing changes and merging\nchanges between branches. The compilation speed can be increased with\nccache if need be.\n-- \nSincerely,\n Stephen R. van den Berg.\n\"There are three types of people in this world: those who make things happen,\n those who watch things happen and those who wonder what happened.\"\n"},{"id":"85795","messageId":"20080731185251.GR32184@machine.or.cz","threadId":"14777","inReplyTo":"20080731183317.GA31085@cuci.nl","subject":"Re: Git vs Monotone","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-31T18:52:51Z","receivedAt":"2008-07-31T18:52:51Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Jul 31, 2008 at 08:33:17PM +0200, Stephen R. van den Berg wrote:\n> Sverre Rabbelier wrote:\n> >If I clone the git mirror of our monotone repository, I find a\n> >checkout size of 148 MB after git-repack--running git-gc also\n> >increased the size by 2 MB, but I'll stick with the initial checkout\n> >size for fairness. If I multiply this by my 11 checkouts, I will have\n> >1628 MB. This is even more compelling for me, as I now save 728 MB of\n> >disk space with monotone.\"\n> \n> You have at least two options to reduce diskspace:\n> a. Clone once from remote, then clone from that clone, it should\n> hardlink the larger packfiles to the initial clone and therefore not\n> cost you a lot.\n> b. Clone once from remote, and create 11 branches inside the new cloned\n> repo. Switch branches while doing development.\n> \n> Most git users pick b. It's easier to work with. Having 11 unpacked\n> repos means that all the object files in those trees are almost up to\n> date, but it adds to the complexity of comparing changes and merging\n> changes between branches. The compilation speed can be increased with\n> ccache if need be.\n\nc. Still clone from the remote, but set up alternates to a single\nlocal \"reference repository\". Then all common objects will be stored\nonly once in this reference repository. The advantage to (a) is that\nyour remotes are actually set up sensibly.\n\n(Note that the blog post talks about .git + checkout sizes, in case\nsomeone got confused like I did, counting only .git. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nAs in certain cults it is possible to kill a process if you know\nits true name. -- Ken Thompson and Dennis M. Ritchie\n"},{"id":"85798","messageId":"20080731190209.GA8372@sigill.intra.peff.net","threadId":"14777","inReplyTo":"bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com","subject":"Re: Git vs Monotone","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-31T19:02:09Z","receivedAt":"2008-07-31T19:02:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:\n\n> If I clone the git mirror of our monotone repository, I find a\n> checkout size of 148 MB after git-repack--running git-gc also\n> increased the size by 2 MB, but I'll stick with the initial checkout\n> size for fairness. If I multiply this by my 11 checkouts, I will have\n> 1628 MB. This is even more compelling for me, as I now save 728 MB of\n> disk space with monotone.\"\n\nYikes. This is not even remotely a fair comparison to monotone, which is\nkeeping a central db.\n\n> I'm in the process of cloning the repo myself, and will check if doing\n> a more aggressive (high --window and --depth values) repack will get\n> us below that 148, but I'm thinking it's just that big a repo. Anyway,\n\nIt's much better than that. I just cloned\n\n git://github.com/felipec/pidgin-clone.git\n\nand the _whole thing_ is 148M, including the working tree. His object db\nis only 88M. So he can do his 11 trees in 61 * 11 + 88 = 759M, saving\n141M over monotone.\n\nAnd I am repacking with insane depth and window right now to see if we\ncan get it smaller (though really, it is not that big a deal, since the\nsize is dominated by his 11 working trees).\n\n-Peff\n"},{"id":"85802","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A5EB@emailmn.mqsoftware.com","threadId":"14777","inReplyTo":"20080731190209.GA8372@sigill.intra.peff.net","subject":"RE: Git vs Monotone","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-31T19:11:25Z","receivedAt":"2008-07-31T19:11:25Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org \n> [mailto:git-owner@vger.kernel.org] On Behalf Of Jeff King\n> Sent: Thursday, July 31, 2008 2:02 PM\n> To: sverre@rabbelier.nl\n> Cc: Git Mailinglist\n> Subject: Re: Git vs Monotone\n> \n> On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:\n> \n> > If I clone the git mirror of our monotone repository, I find a \n> > checkout size of 148 MB after git-repack--running git-gc also \n> > increased the size by 2 MB, but I'll stick with the initial \n> checkout \n> > size for fairness. If I multiply this by my 11 checkouts, I \n> will have\n> > 1628 MB. This is even more compelling for me, as I now save \n> 728 MB of \n> > disk space with monotone.\"\n> \n> Yikes. This is not even remotely a fair comparison to \n> monotone, which is keeping a central db.\n> \nI think it is a fair comparison, but as you point out, the author is\ndoing the comparison wrong. Monotone's \"central db\" (as you call it) is\nreally equivalent to git's object database.\n\n> > I'm in the process of cloning the repo myself, and will \n> check if doing \n> > a more aggressive (high --window and --depth values) repack \n> will get \n> > us below that 148, but I'm thinking it's just that big a \n> repo. Anyway,\n> \n> It's much better than that. I just cloned\n> \n> git://github.com/felipec/pidgin-clone.git\n> \n> and the _whole thing_ is 148M, including the working tree. \n> His object db is only 88M. So he can do his 11 trees in 61 * \n> 11 + 88 = 759M, saving 141M over monotone.\n> \nRight, that's been my experience too, that git is smaller than monotone.\nThe author just needs to compare eqivalent concepts ;-)\n\n> -Peff\n> --\n\nCheers,\nCraig\n"},{"id":"85804","messageId":"alpine.LFD.1.10.0807311211260.3277@nehalem.linux-foundation.org","threadId":"14777","inReplyTo":"bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com","subject":"Re: Git vs Monotone","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-31T19:17:32Z","receivedAt":"2008-07-31T19:17:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, Sverre Rabbelier wrote:\n> \n> I just read this blog post [0] in which one of the Pidgin devs sheds\n> his light on their 'tool choice'. In the post he mentions the\n> following figures:\n\nDon't even bother. The guy is apparently not even trying to work with his \ntools, he just has an agenda to push.\n\nQuite frankly, anybody who wants to stay with monotone, we should \n_encourage_ them. They add nothing to any possible project, because they \nare clearly not very intelligent.\n\nThe guy is apparently happy using a single database for monotone (which \napparently has a database that is two times the size of the git one), but \nthen doesn't want to use a single database for git, but wants to force a \nfull clone for each. Not to mention that in git, you'd normally not do 11 \nclones to begin with, you'd just do 11 branches in one repo.\n\nSo there is no point discussing things with people like that. If he wants \nto skew things in monotone's favor, he can do it. Let him. \n\n\t\t\tLinus\n"},{"id":"85803","messageId":"bd6139dc0807311219h670f782cm8bed74bed2b4558@mail.gmail.com","threadId":"14777","inReplyTo":"20080731190209.GA8372@sigill.intra.peff.net","subject":"Re: Git vs Monotone","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-31T19:19:41Z","receivedAt":"2008-07-31T19:19:41Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Thu, Jul 31, 2008 at 21:02, Jeff King wrote:\n> and the _whole thing_ is 148M, including the working tree. His object db\n> is only 88M. So he can do his 11 trees in 61 * 11 + 88 = 759M, saving\n> 141M over monotone.\n\nYeah, that's rather unfair indeed, counting that way he'd have to add\nthe 229MB for the Monotone db too ;).\n\n> And I am repacking with insane depth and window right now to see if we\n> can get it smaller (though really, it is not that big a deal, since the\n> size is dominated by his 11 working trees).\n\nI repacked with --depth=100 and --window=100, I tried out 500 at first\nbut it was just insanely slow (on a VM with one 2.4Ghz Core\navailable). This resulted in a .git dir of 76MB. With that dir I did\nthe following:\n$mkdir pidgins\n$git clone --no-hardlinks --bare pidgin pidgin-bare\n$mv pidgin-bare pidgins\n$cd pidgins\n$for i in 1 2 3 4 5 6 7 8 9 10 11; do git clone pidgin-bare pidgin$i; done\n$ du -sh .\n742M .\n\nSo... monotone, eat your heart out ;).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85805","messageId":"20080731192405.GC20819@mit.edu","threadId":"14777","inReplyTo":"bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com","subject":"Re: Git vs Monotone","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-31T19:24:05Z","receivedAt":"2008-07-31T19:24:05Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:\n> \n> I just read this blog post [0] in which one of the Pidgin devs sheds\n> his light on their 'tool choice'. In the post he mentions the\n> following figures:\n\nThe main thing this proves was that the Pidgin devs were most familiar\nwith Monotone, and weren't sufficiently familiar with git; hence, they\ndidn't know how to do a fair comparison. First of all, sure, if they\nare willing to use a single working directory and want to switch\nbetween branches using \"git checkout\", that works well. But suppose\nthey really want separate working directories. The simplist and\neasist way is to use \"git clone -s\".\n\nSo if they do:\n\ngit clone git://github.com/felipec/pidgin-clone.git pidgin\ngit clone -s pidgin clone-1\ngit clone -s pidgin clone-2\ngit clone -s pidgin clone-3\ngit clone -s pidgin clone-4\ngit clone -s pidgin clone-5\ngit clone -s pidgin clone-6\ngit clone -s pidgin clone-7\ngit clone -s pidgin clone-8\ngit clone -s pidgin clone-9\ngit clone -s pidgin clone-10\n\nThe net disk usage is 746 megabytes, as compared to the 900 megabytes\nclaimed in the blog post. The main difference is the git database is\nonly takes 87 megabytes, compared to the 229 megabytes for the\nMonotone database. The main issue is the pidgin developers simply\ndidn't know how to use the -s flag so they didn't need to duplicate\nthe git database for every single clone.\n\nShrug; whatever, I've always said the biggest issue for any tool is\nwhat the developers are familiar with. It may be that monotone was\nthe right choice for the pidgin core developers, if they weren't\nfamiliar enough with git.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"85806","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A5EC@emailmn.mqsoftware.com","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311211260.3277@nehalem.linux-foundation.org","subject":"RE: Git vs Monotone","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-31T19:28:21Z","receivedAt":"2008-07-31T19:28:21Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> [mailto:git-owner@vger.kernel.org] On Behalf Of Linus Torvalds\n> Sent: Thursday, July 31, 2008 2:18 PM\n> Subject: Re: Git vs Monotone\n> \n> On Thu, 31 Jul 2008, Sverre Rabbelier wrote:\n> > \n> The guy is apparently happy using a single database for \n> monotone (which apparently has a database that is two times \n> the size of the git one), but then doesn't want to use a \n> single database for git, but wants to force a full clone for \n> each. Not to mention that in git, you'd normally not do 11 \n> clones to begin with, you'd just do 11 branches in one repo.\n> \n\nHaving come from monotone to git recently, I have to say that it isn't\nimmediately obvious how you get the single database for git a la\nmonotone (with remotes that point to the right place, etc.). At first,\nI also thought that you didn't share the object database on clones and I\nhad to discover that myself. It's possible that I'm just an idiot too\n;-)\n\n> So there is no point discussing things with people like that. \n> If he wants to skew things in monotone's favor, he can do it. \n> Let him. \n> \n\nIt's possible he's doing that, but it's also possible he just isn't that\nfamiliar with git.\n\n> \t\t\tLinus\n> --\n\nCheers,\nCraig\n"},{"id":"85808","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A5EE@emailmn.mqsoftware.com","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311211260.3277@nehalem.linux-foundation.org","subject":"Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-31T19:48:21Z","receivedAt":"2008-07-31T19:48:21Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org \n> [mailto:git-owner@vger.kernel.org] On Behalf Of Linus Torvalds\n> Sent: Thursday, July 31, 2008 2:18 PM\n\n> single database for git, but wants to force a full clone for \n> each. Not to mention that in git, you'd normally not do 11 \n> clones to begin with, you'd just do 11 branches in one repo.\n> \n\nI have a question about this. I asked this awhile back and didn't\nreally get any satisfactory answers except to use git-new-workdir, which\nmakes git behave a lot like monotone. In our workflow, we do create\nbranches for nearly everything, but we do find that we have a need to\nkeep the build artifacts of those branches isolated from each other\nbecause rebuilding is expensive. IOW, we have this sort of workflow:\n\ngit checkout A\n[work on A, build, test, do some commits]\ngit checkout B\n[work on B, build, test, do some commits]\ngit checkout A\n[work on A, re-build, test, do some commits]\n\nWe find ourselves constantly having to shift gears and work on other\nthings in the middle of whatever it is we're currently working on. For\ninstance, in the scenario above, A might be branch that contains a\nfeature going into our next release. B might be a bugfix and takes\npriority over A, so you have to leave A as-is and start work on B. When\nI come back to work on A, I have to rebuild A to continue working, and\nthat's just too expensive for us. So we use the monotone-like\nnew-workdir which allows us to save those build artifacts.\n\nSo, that said, I ask again, am I missing something? Is there a better\nway to do this? How do the kernel developers do this, surely they're\nswitching branches back and forth having to build in-between?\n\n> \t\t\tLinus\n> --\n> To unsubscribe from this list: send the line \"unsubscribe \n> git\" in the body of a message to majordomo@vger.kernel.org \n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\nCheers,\nCraig\n"},{"id":"85809","messageId":"alpine.LFD.1.10.0807311244240.3277@nehalem.linux-foundation.org","threadId":"14777","inReplyTo":"63BEA5E623E09F4D92233FB12A9F79430238A5EC@emailmn.mqsoftware.com","subject":"RE: Git vs Monotone","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-31T19:52:43Z","receivedAt":"2008-07-31T19:52:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, Craig L. Ching wrote:\n> \n> It's possible he's doing that, but it's also possible he just isn't that\n> familiar with git.\n\nPossible. But it really sounded like he didn't even try. Because quite \nfrankly, if he had even bothered to _try_, he wouldn't have gotten the \nnumbers he got.\n\nThe fact is, even without \"-s\", a local clone will do hardlinks for the \ndatabase. And since the original pack-file is marked as a 'keep' file, \nthat original pack-file won't even be broken apart.\n\nSo literally, if he had just bothered to even _try_ the git setup, he'd \nhave noticed that git actually uses less disk than monotone would do. But \nit sounds like he didn't even try it.\n\nSo completely ignoring the fact that you could do a single database with \ngit, and completely ignoring the fact that with git you'd probably use \nbranches for at least some of those 11 repos anyway, he'd _still_ have had \nless disk space used by git unless he would do something intentionally odd \n(like clone all the repositories over the network separately).\n\n\t\t\tLinus\n"},{"id":"85810","messageId":"alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org","threadId":"14777","inReplyTo":"63BEA5E623E09F4D92233FB12A9F79430238A5EE@emailmn.mqsoftware.com","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-31T20:09:09Z","receivedAt":"2008-07-31T20:09:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, Craig L. Ching wrote:\n> \n> We find ourselves constantly having to shift gears and work on other\n> things in the middle of whatever it is we're currently working on. For\n> instance, in the scenario above, A might be branch that contains a\n> feature going into our next release. B might be a bugfix and takes\n> priority over A, so you have to leave A as-is and start work on B. When\n> I come back to work on A, I have to rebuild A to continue working, and\n> that's just too expensive for us. So we use the monotone-like\n> new-workdir which allows us to save those build artifacts.\n> \n> So, that said, I ask again, am I missing something? Is there a better\n> way to do this? How do the kernel developers do this, surely they're\n> switching branches back and forth having to build in-between?\n\nSure, if you want to keep the build tree around, you would probably not \nuse branches. \n\nBut yes, then you'd likely do \"git clone -s\" with some single \"common \npoint\" or use \"git worktree\". And even if you don't use \"-s\", you should \n_still_ effectively share at least all the old history (which tends to be \nthe bulk) thanks to even a default \"git clone\" will just hardlink the \npack-files.\n\nSo literally, if you do\n\n\tgit clone \n\nand then do\n\n\tgit clone \n\tgit clone \n\nthen all of those will all share the initial pack-file on-disk. Try it.\n\n(You may then want to edit the \"origin\" branch info in the .git/config to \npoint to the network one etc, of course).\n\nOh, and to make sure I'm not lying I actually did test this, but I also \nnoticed that \"git clone\" no longer marks the initial pack-file with \n\"keep\", so it looks like \"git gc\" will then break the link. That's sad. I \nwonder when that changed, or maybe I'm just confused and it never did.\n\nJunio?\n\n\t\tLinus\n"},{"id":"85811","messageId":"20080731201855.GB24631@spearce.org","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-31T20:18:55Z","receivedAt":"2008-07-31T20:18:55Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> \n> Oh, and to make sure I'm not lying I actually did test this, but I also \n> noticed that \"git clone\" no longer marks the initial pack-file with \n> \"keep\", so it looks like \"git gc\" will then break the link. That's sad. I \n> wonder when that changed, or maybe I'm just confused and it never did.\n\nIt was a bug in git-clone that we were recording the .keep file on\ninitial clone. We left the lock file in place after the fetch pack\ncall was done, but didn't remove it after the refs were updated.\n\nIf we want to go back to .keep'ing the original pack creating\nduring clone it probably should be threshold based. For many\nsmaller projects with only a 25M pack (or less) there is no point\nin .keep'ing that first pack. For larger projects where the pack\nis over a few hundred megabytes, then yea, maybe there is value\nin .keep'ing it during clone.\n\n-- \nShawn.\n"},{"id":"85813","messageId":"7vmyjxyf7a.fsf@gitster.siamese.dyndns.org","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311244240.3277@nehalem.linux-foundation.org","subject":"Re: Git vs Monotone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-31T20:24:41Z","receivedAt":"2008-07-31T20:24:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> ... And since the original pack-file is marked as a 'keep' file,\n> that original pack-file won't even be broken apart.\n\nOops, isn't that something we fixed recently as a \"bug\"?\n\n> So completely ignoring the fact that you could do a single database with \n> git, and completely ignoring the fact that with git you'd probably use \n> branches for at least some of those 11 repos anyway, he'd _still_ have had \n> less disk space used by git unless he would do something intentionally odd \n> (like clone all the repositories over the network separately).\n\nWell, people are not perfect and they are free to express their opinions\nbased on faulty understanding of reality on their blogs. The right things\nto do are (1) ignore them on the list and not waste many people's time,\nand/or (2) educate them, but in private or in a circle where many other\nsimilar ignorants benefit from such education. That is not here but\nperhaps on #monotone channel?\n"},{"id":"85816","messageId":"alpine.LFD.1.10.0807311328500.3277@nehalem.linux-foundation.org","threadId":"14777","inReplyTo":"7vmyjxyf7a.fsf@gitster.siamese.dyndns.org","subject":"Re: Git vs Monotone","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-31T20:30:50Z","receivedAt":"2008-07-31T20:30:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > ... And since the original pack-file is marked as a 'keep' file,\n> > that original pack-file won't even be broken apart.\n> \n> Oops, isn't that something we fixed recently as a \"bug\"?\n\nEhh, apparently. I had thought it was a feature (not that it was me who \nimplemented it), and didn't realize that others thought it was a bug. \nOops.\n\nThe default *.keep file was _wonderful_ for cloning a large tree onto a \nsmall machine. It did exactly the right thing (never mind any shared \nrepositories - it just made repacking much more reasonable).\n\nSo maybe it was unintentional (a \"bug\"), but I had always seen it as being \nsomething good.\n\n\t\t\tLinus\n"},{"id":"85814","messageId":"20080731203206.GA8668@sigill.intra.peff.net","threadId":"14777","inReplyTo":"bd6139dc0807311219h670f782cm8bed74bed2b4558@mail.gmail.com","subject":"Re: Git vs Monotone","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-31T20:32:06Z","receivedAt":"2008-07-31T20:32:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 31, 2008 at 09:19:41PM +0200, Sverre Rabbelier wrote:\n\n> I repacked with --depth=100 and --window=100, I tried out 500 at first\n> but it was just insanely slow (on a VM with one 2.4Ghz Core\n> available). This resulted in a .git dir of 76MB. With that dir I did\n> the following:\n\nI tried 200/200 and got a 74M packfile. So I think we're getting into\ndiminishing returns.\n\n> $ du -sh .\n> 742M .\n> \n> So... monotone, eat your heart out ;).\n\n:)\n\n-Peff\n"},{"id":"85817","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A5FF@emailmn.mqsoftware.com","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org","subject":"RE: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-31T20:37:30Z","receivedAt":"2008-07-31T20:37:30Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":"\n> From: Linus Torvalds [mailto:torvalds@linux-foundation.org] \n> Sent: Thursday, July 31, 2008 3:09 PM\n> \n> Sure, if you want to keep the build tree around, you would \n> probably not use branches. \n> \n\nI think we'd still use branches, but we just need to isolate their\nworkdirs from each other.\n\n> But yes, then you'd likely do \"git clone -s\" with some single \n> \"common point\" or use \"git worktree\". And even if you don't \n> use \"-s\", you should _still_ effectively share at least all \n> the old history (which tends to be the bulk) thanks to even a \n> default \"git clone\" will just hardlink the pack-files.\n> \n> So literally, if you do\n> \n> \tgit clone \n> \n> and then do\n> \n> \tgit clone \n> \tgit clone \n> \n> then all of those will all share the initial pack-file \n> on-disk. Try it.\n> \n> (You may then want to edit the \"origin\" branch info in the \n> .git/config to point to the network one etc, of course).\n> \n\nYes, thank you for the explanation. Having used git a fair amount now,\nthat makes perfect sense to me, in fact, it sounds a lot like\ngit-new-workdir, but I think I'll change our use of git-new-workdir to\nsomething more \"core\" git. It seems to me that maybe this is something\nthat could be documented more prominently? Or maybe it is and I've just\nmissed it. This would have saved me a lot of time originally to be\nsure.\n\n> Oh, and to make sure I'm not lying I actually did test this, \n> but I also noticed that \"git clone\" no longer marks the \n> initial pack-file with \"keep\", so it looks like \"git gc\" will \n> then break the link. That's sad. I wonder when that changed, \n> or maybe I'm just confused and it never did.\n> \n\nWhat's the consequence of that then? Because of that, would you say\n\"don't gc your master local repo until all derived repos are merged?\"\nIf that link is broken is it just a loss of space? Or is it more?\n\n> \t\tLinus\n> \n\nThanks again!\n\nCheers,\nCraig\n"},{"id":"85818","messageId":"8778C923356C6541B263428246AE9C2A4FE2966B09@NA-MAIL-2-2.rws.ad.ea.com","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311244240.3277@nehalem.linux-foundation.org","subject":"RE: Git vs Monotone","fromName":"Blum, Robert","fromEmail":"rblum@pandemicstudios.com","sentAt":"2008-07-31T20:42:08Z","receivedAt":"2008-07-31T20:42:08Z","isPatch":false,"sender":{"key":"rblum@pandemicstudios.com","avatar":null},"body":"\n>The fact is, even without \"-s\", a local clone will do hardlinks for the\n>database. And since the original pack-file is marked as a 'keep' file,\n>that original pack-file won't even be broken apart.\n\nThen again, Pidgin is, among other things, a Windows project. I.e. hardlinks are not exactly trivial. There's a good chance nobody jumped through the hoops of junction points for git on win32... (Somebody correct me if I'm wrong)\n\n>So literally, if he had just bothered to even _try_ the git setup, he'd\n>have noticed that git actually uses less disk than monotone would do. But\n>it sounds like he didn't even try it.\n\nWell, he *did* try it, for *one* repository. He just didn't know that there's a better way than having 11 clones. And I lay the blame for that squarely at the git documentation ;)\n\nYes, I know, why don't I make it better...?\n\nBecause I'm fairly new to git and would feel like an idiot 'documenting' something that I feel I've only scratched the surface of. I do expect to write a few uninformed rants on my blog, though. And maybe at some point, I can contribute to actual docs :)\n\nEither way, it's another interesting data point for all of us still comparing DVCSs. I just wish he had comments on his blog so somebody could inform him that he's mistaken...\n\n\n - Robert\n"},{"id":"85820","messageId":"20080731205400.GA7911@atjola.homenet","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-07-31T20:54:00Z","receivedAt":"2008-07-31T20:54:00Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.07.31 13:09:09 -0700, Linus Torvalds wrote:\n> \n> \n> On Thu, 31 Jul 2008, Craig L. Ching wrote:\n> > \n> > We find ourselves constantly having to shift gears and work on other\n> > things in the middle of whatever it is we're currently working on. For\n> > instance, in the scenario above, A might be branch that contains a\n> > feature going into our next release. B might be a bugfix and takes\n> > priority over A, so you have to leave A as-is and start work on B. When\n> > I come back to work on A, I have to rebuild A to continue working, and\n> > that's just too expensive for us. So we use the monotone-like\n> > new-workdir which allows us to save those build artifacts.\n> > \n> > So, that said, I ask again, am I missing something? Is there a better\n> > way to do this? How do the kernel developers do this, surely they're\n> > switching branches back and forth having to build in-between?\n> \n> Sure, if you want to keep the build tree around, you would probably not \n> use branches. \n> \n> But yes, then you'd likely do \"git clone -s\" with some single \"common \n> point\" or use \"git worktree\". And even if you don't use \"-s\", you should \n> _still_ effectively share at least all the old history (which tends to be \n> the bulk) thanks to even a default \"git clone\" will just hardlink the \n> pack-files.\n> \n> So literally, if you do\n> \n> \tgit clone \n\nHum, I guess I'm just missing something and prepare to get flamed, but\nwouldn't you want that one to be bare? Otherwise, the other clones won't\nsee all of the original repo's branches, right?\n\nMaybe even better:\n\nmkdir local-mirror\ncd local-mirror\ngit --bare init\ngit remote add -f --mirror origin \n\nA cronjob (or whatever) could keep the local mirror up-to-date and the\nother repos can fetch from there. Pushing would need to go to a\ndifferent remote then though.. Humm... Maybe not worth the trouble for a\nbit of additional object sharing.\n\nBjörn\n"},{"id":"85822","messageId":"BLU0-SMTP273E4683B41DB7E44122F0AE7C0@phx.gbl","threadId":"14777","inReplyTo":"63BEA5E623E09F4D92233FB12A9F79430238A5EE@emailmn.mqsoftware.com","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Sean Estabrooks","fromEmail":"seanlkml@sympatico.ca","sentAt":"2008-07-31T20:57:24Z","receivedAt":"2008-07-31T20:57:24Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 31 Jul 2008 14:48:21 -0500\n\"Craig L. Ching\" wrote:\n\n> I have a question about this. I asked this awhile back and didn't\n> really get any satisfactory answers except to use git-new-workdir, which\n> makes git behave a lot like monotone. In our workflow, we do create\n> branches for nearly everything, but we do find that we have a need to\n> keep the build artifacts of those branches isolated from each other\n> because rebuilding is expensive. IOW, we have this sort of workflow:\n\nIs there a problem using git-new-workdir? It sounds like it does\nexactly what you want.\n\n> We find ourselves constantly having to shift gears and work on other\n> things in the middle of whatever it is we're currently working on. For\n> instance, in the scenario above, A might be branch that contains a\n> feature going into our next release. B might be a bugfix and takes\n> priority over A, so you have to leave A as-is and start work on B. When\n> I come back to work on A, I have to rebuild A to continue working, and\n> that's just too expensive for us. So we use the monotone-like\n> new-workdir which allows us to save those build artifacts.\n> \n> So, that said, I ask again, am I missing something? Is there a better\n> way to do this? How do the kernel developers do this, surely they're\n> switching branches back and forth having to build in-between?\n\nA decent build system will only compile the source files that actually\nchanged when switching branches. Couple that with a compiler cache\n(such as ccache) and switching between branches in the kernel or git\nproject usually isn't prohibitively time consuming.\n\nSean\n"},{"id":"85825","messageId":"32541b130807311410w6884c303i9f89fea3887f934b@mail.gmail.com","threadId":"14777","inReplyTo":"20080731205400.GA7911@atjola.homenet","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-31T21:10:50Z","receivedAt":"2008-07-31T21:10:50Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/31/08, Björn Steinbrink wrote:\n> Maybe even better:\n>\n> mkdir local-mirror\n> cd local-mirror\n> git --bare init\n> git remote add -f --mirror origin \n>\n> A cronjob (or whatever) could keep the local mirror up-to-date and the\n> other repos can fetch from there. Pushing would need to go to a\n> different remote then though.. Humm... Maybe not worth the trouble for a\n> bit of additional object sharing.\n\nWhat would be *really* great is if we could find a way for multiple\nlocal clones to share the same objects, refs, and configuration - ie.\nwithout pushing and pulling between them at all. Then they could\n*all* point at the remote upstream repo through \"origin\", and\npushing/pulling with that repo would update the objects and refs for\nall the local repos.\n\nI'm not sure of the best way to do this, though. In particular, it\nseems like having multiple work trees checked out on the same ref\ncould be problematic.\n\nIs that just what git-new-workdir is for? (It seems to be\nundocumented so it's hard to tell.) And what about this\n.gitlink/.gitfile stuff I've heard about? Could I use that to have\nmultiple work trees share the same .git folder?\n\nThanks,\n\nAvery\n"},{"id":"85827","messageId":"alpine.LFD.1.10.0807311357430.3277@nehalem.linux-foundation.org","threadId":"14777","inReplyTo":"20080731205400.GA7911@atjola.homenet","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-31T21:13:06Z","receivedAt":"2008-07-31T21:13:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, Björn Steinbrink wrote:\n> > \n> > So literally, if you do\n> > \n> > \tgit clone \n> \n> Hum, I guess I'm just missing something and prepare to get flamed, but\n> wouldn't you want that one to be bare? Otherwise, the other clones won't\n> see all of the original repo's branches, right?\n\nMaking it bare might be a good idea for other reasons too (it makes it \nmuch more obvious that it's a \"local clone\" and is somehow special). But \nit's really a matter of taste - and the project - exactly how you do it. \n\nFor example, the kernel only has a single master branch in the top repo, \nso there it really doesn't matter, and yes, I'm more kernel-oriented than \nanything else, of course.\n\nBut I don't think it's exactly wrong to have the initial clone be a real \nrepository that you do work in. Quite often the history really is the \n_bulk_ of the database by far (at least with projects that have big enough \nrepositories for this to even matter in the first place!), and as long as \nyou just download that once and share that thing, you're already ahead of \nthe game and the rest is really just details.\n\n> Maybe even better:\n> \n> mkdir local-mirror\n> cd local-mirror\n> git --bare init\n> git remote add -f --mirror origin \n> \n> A cronjob (or whatever) could keep the local mirror up-to-date and the\n> other repos can fetch from there.\n\nHeh. You can certainly do it many ways. I suspect the _easiest_ model is \nactually to do one single local repo that is special (and perhaps bare), \nand then you can clone all the other ones with\n\n\tgit clone --reference \n\nbecause that will automatically set up the new local repo to have the \nlocal reference as an alternates thing, and will avoid downloading \nunnecessary stuff.\n\nSo my point about the eleven repos was not that it's the best way to do \none remote clone and then eleven local ones - my point was that even if \nyou do that _stupid_ thing, you'd have seen sharing without even knowing \nwhat you really did.\n\nIf you want to explicitly share, I think the local bare reference and \nusing \"git clone --reference\" is the best way. It sets up a special \nlink-file (it's just a text-file that git knows about, so it should work \nfine under Windows too - no need for filesystem support) in \n.git/objects/info/alternates.\n\nIOW, git-clone --reference works like \"git clone -s\", but does so with one \nspecial local database, while allowing you to clone from anywhere. Very \nconvenient.\n\nAnd no, I don't think we document all these \"tricks\" very well. Partly \nbecause people are _already_ complaining about how git can do so many \nthings ;) But partly because if you don't know what you're doing, the \n\"tricks\" are often things you really need to understand, and can be a bit \ndangerous otherwise.\n\nFor example, the \"git clone -s\" (or --reference) thing is *very* useful, \nbut one result of other repositories then sharing a database with the \nreference one is that suddenly the reference repo is very special. You \nmust not remove it (obviously!), but you also must not rebase it and prune \nit etc.\n\nSo all the normal git workflows are at least designed to be _safe_ even in \nthe absense of people not knowing what they are doing. The duplication may \nbe using harddisk space, but\n\n - quite often the checkout is actually an even bigger issue, and the git \n repo is small enough that lots of people don't really worry.\n\n - duplicating the repo also means that you cannot _possibly_ screw up \n other people/repos and does give you a kind of backup (even if \n same-disk backups are obviously of dubious use: they shouldn't be your \n _primary_ backup, but having multiple copies on a single disk still \n protects against a _lot_ of problems)\n\nso... It's a trade-off.\n\n\t\t\tLinus\n"},{"id":"85829","messageId":"20080731212215.GI20819@mit.edu","threadId":"14777","inReplyTo":"BLU0-SMTP273E4683B41DB7E44122F0AE7C0@phx.gbl","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-31T21:22:15Z","receivedAt":"2008-07-31T21:22:15Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jul 31, 2008 at 04:57:24PM -0400, Sean Estabrooks wrote:\n> > We find ourselves constantly having to shift gears and work on other\n> > things in the middle of whatever it is we're currently working on. For\n> > instance, in the scenario above, A might be branch that contains a\n> > feature going into our next release. B might be a bugfix and takes\n> > priority over A, so you have to leave A as-is and start work on B. When\n> > I come back to work on A, I have to rebuild A to continue working, and\n> > that's just too expensive for us. So we use the monotone-like\n> > new-workdir which allows us to save those build artifacts.\n>\n> A decent build system will only compile the source files that actually\n> changed when switching branches. Couple that with a compiler cache\n> (such as ccache) and switching between branches in the kernel or git\n> project usually isn't prohibitively time consuming.\n\nThat being said, if the bugfix is on a \"maint\" branch, and one of the\nthings that has changed is a header file that forces most of the\nproject to be recompiled, a separate work directory may be more\nconvenient. Of course, a separate work directory (whether created\nusing \"git clone -s\" or \"git-new-workdir\" means more disk space and it\nmeans greater use of the page cache or a slowdown while the different\nsets of sources get paged in and out. Of course, you could hack\ngit-work-dir to use cp -rl to initially copy the working directory\nusing hard links, and then when the new branch is checked out, if most\nof the files haven't changed, the files in the working directory could\nbe shared too. A lot depends on how much you want to squeeze the last\nbit of hard drive and speed optimization, and how big your project is.\n\n \t \t \t \t\t - Ted\n"},{"id":"85834","messageId":"alpine.LFD.1.10.0807311426090.3277@nehalem.linux-foundation.org","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-31T21:40:55Z","receivedAt":"2008-07-31T21:40:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, Linus Torvalds wrote:\n> \n> Sure, if you want to keep the build tree around, you would probably not \n> use branches. \n\nSide note: it's often faster to recompile, if your project has a good \nbuild system.\n\nFor example, for the kernel, I can literally rebuild my whole kernel \n(which is just what I use on _that_ machine) in about 16 seconds. This is \n_not_ using ccache or anything else - it's rebuilding the whole tree with \n-j16.\n\nIt turns out that using multiple build trees would actually slow things \ndown, because then the source code wouldn't fit in memory any more. If I \nhave to actually read the source code from the disk, my nice 16-second \ncompile goes up to a minute or more.\n\nNow, the thing you should take away from this is:\n\n - kernel people have cool toys, and CPU's that are faster than what you \n have. Nyaah, nyaah.\n\n - disk is slow. REALLY slow. If you can share most of a single source \n tree and thus keep it in memory, you're ahead.\n\n - even large projects can have a fast build cycle if your build chain \n doesn't suck. The kernel is larger than most, but a _lot_ of build \n systems don't parallelize or use horribly inefficient tools, so they \n take much longer to build. \n\nThe last part is the thing that people often stumble on. For example, I \ncan literally compile the kernel a hell of a lot faster than I can do \n\"make doc\" on the git tree! Even just trying a \"make -j16\" when building \nthe git documentation is really really really painful. I suspect I'd need \na ton more memory for that horror.\n\nSo if your workflow involves xml (I think the doc build for git is all \nxsltproc - along with asciidoc written in python or something), you're \nscrewed. But in the kernel we've actually cared pretty deeply about build \ntimes, and as a result it's actually very pleasant to switch branches and \njust rebuild. Even if some core header file has changed, it's _still_ ok \nif you've got enough CPU.\n\n(I just tested - I can do a \"make doc\" for git in just under a minute from \na clean tree. Ouch. That really is three times longer than my kernel \nbuild - as long as I brought the kernel and compiler into memory first ;)\n\n\t\t\tLinus\n"},{"id":"85831","messageId":"46a038f90807311443q2bbf7782kbbf339ab77376dc7@mail.gmail.com","threadId":"14777","inReplyTo":"20080731205400.GA7911@atjola.homenet","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2008-07-31T21:43:48Z","receivedAt":"2008-07-31T21:43:48Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Fri, Aug 1, 2008 at 8:54 AM, Björn Steinbrink wrote:\n>> So literally, if you do\n>>\n>> git clone \n>\n> Hum, I guess I'm just missing something and prepare to get flamed, but\n> wouldn't you want that one to be bare? Otherwise, the other clones won't\n> see all of the original repo's branches, right?\n\nYes, that's why\n\n git clone --reference /path/to/fat/checkout/.git/ \n\nis far better. Each \"thin\" checkout sees the central repo normally,\nbut they borrow the object store from the referenced local \"fat\"\ncheckout.\n\ncheers,\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"85854","messageId":"20080801025024.GA18529@anvil.corenet.prv","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311426090.3277@nehalem.linux-foundation.org","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Dmitry Torokhov","fromEmail":"dmitry.torokhov@gmail.com","sentAt":"2008-08-01T02:50:24Z","receivedAt":"2008-08-01T02:50:24Z","isPatch":false,"sender":{"key":"dmitry.torokhov@gmail.com","avatar":null},"body":"On Thu, Jul 31, 2008 at 02:40:55PM -0700, Linus Torvalds wrote:\n> \n> \n> On Thu, 31 Jul 2008, Linus Torvalds wrote:\n> > \n> > Sure, if you want to keep the build tree around, you would probably not \n> > use branches. \n> \n> Side note: it's often faster to recompile, if your project has a good \n> build system.\n> \n> For example, for the kernel, I can literally rebuild my whole kernel \n> (which is just what I use on _that_ machine) in about 16 seconds. This is \n> _not_ using ccache or anything else - it's rebuilding the whole tree with \n> -j16.\n> \n\nIs it after make mrproper (wow)? Or is it when your branches are\n\"recent\"? Because for me (and well, I dont have that beefy boxes as you\ndo) swithing between \"for-linus\" and \"next\" that based off a revision in\nvicinity of 2.6.xx-rc1 and \"work\" which tracks the tip of your tree\ntakes time to rebuild.\n\n-- \nDmitry\n"},{"id":"85856","messageId":"alpine.LFD.1.10.0807311956040.3277@nehalem.linux-foundation.org","threadId":"14777","inReplyTo":"20080801025024.GA18529@anvil.corenet.prv","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-01T03:02:51Z","receivedAt":"2008-08-01T03:02:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, Dmitry Torokhov wrote:\n\n> > For example, for the kernel, I can literally rebuild my whole kernel \n> > (which is just what I use on _that_ machine) in about 16 seconds. This is \n> > _not_ using ccache or anything else - it's rebuilding the whole tree with \n> > -j16.\n> \n> Is it after make mrproper (wow)?\n\nYeah. It's after doing\n\n\tgit clean -dqfx\n\tmake oldconfig\n\nwhere I tend to use \"git clean -dqfx\" instead of \"make mrproper\" these \ndays. \n\nNote that my \"oldconfig\" really only does the things I need, so this is \n_not_ a \"allmodconfig\" or anything like that. That would take much longer. \nIt only has the drivers I use, and the stuff I actually need (it's not a \nembedded kernel in any way, but it's definitely pared down config exactly \nbecause I like being able to rebuild my kernels without wasting time on \nthousands of drivers that I can't use anyway).\n\nOther people can do the \"does it compile?\" testing. Not worth my time, I \nfeel ;)\n\n> Because for me (and well, I dont have that beefy boxes as you do) \n> swithing between \"for-linus\" and \"next\" that based off a revision in \n> vicinity of 2.6.xx-rc1 and \"work\" which tracks the tip of your tree \n> takes time to rebuild.\n\nWell, the difference really is the beefy box. And the fact that I hate \nmodules, and I hate building stuff that I don't actually need. \n\nI literally turn off CONFIG_MODULES entirely. \n\n\t\t\tLinus\n"},{"id":"85859","messageId":"alpine.LFD.1.10.0807312049050.3277@nehalem.linux-foundation.org","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311956040.3277@nehalem.linux-foundation.org","subject":"Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-01T03:59:34Z","receivedAt":"2008-08-01T03:59:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, Linus Torvalds wrote:\n> \n> Well, the difference really is the beefy box.\n\nBtw, the fact that I have a beefy box really wasn't the point. The fact \nthat I can build the kernel three times quicker than I can build the git \ndocumentation _was_ kind of the point. A lot of projects have horrible \nbuild rules - makefiles that don't parallelize well or just tools that \nsuck dead baby donkeys through a straw.\n\nI often get the feeling that I can compile the kernel faster than I can \nrun \"./configure\" on most of the other projects I ever compile.\n\nSo I'd heartily encourage projects to try to make their build lean and \nmean. It actually then allows you to be more efficient, and gives the \noption of using more efficient development models, where \"use multiple \nbranches in the same tree\" is just one example of that.\n\nOf course, I have to admit that git itself isn't exactly a stellar \nexample. I can compile git itself in basically zero time, but those docs \nreally take a loooong time.\n\nJust one more reason for me to stay away from documentation.\n\n\t\t\tLinus\n"},{"id":"85867","messageId":"bd6139dc0808010023r5d44e7a2ke062c9c39dfb865c@mail.gmail.com","threadId":"14777","inReplyTo":"bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com","subject":"Re: Git vs Monotone","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-08-01T07:23:36Z","receivedAt":"2008-08-01T07:23:36Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Thu, Jul 31, 2008 at 20:13, Sverre Rabbelier wrote:\n> I just read this blog post [0] in which one of the Pidgin devs sheds\n> his light on their 'tool choice'. In the post he mentions the\n> following figures:\n\n> [0] http://theflamingbanker.blogspot.com/2008/07/holy-war-of-tool-choice.html\n\nI have poked him on #pidgin, and he has added the following:\n\n\"Note: It's come to my attention that I had missed the ability to\nshare a git database across multiple working copies. In that scenario,\nthe total size of the database and 11 working copies is slightly under\n750 MB, and thus a space savings in the neighborhood of 150 MB over\nmonotone. It had been my understanding that I needed a copy of the\ndatabase per working copy. I stand corrected. I don't use git on a\ndaily basis, as the projects I work with currently use CVS, SVN, or\nmonotone, so I am bound to miss finer details of git here and there.\nThere are other reasons I prefer to stick with monotone, but I won't\nget into them here, as they're not important to the point of this\npost.\"\n\nSo I'm happy ;).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85882","messageId":"86abfxawgu.fsf@lola.quinscape.zz","threadId":"14777","inReplyTo":"alpine.LFD.1.10.0807311244240.3277@nehalem.linux-foundation.org","subject":"Re: Git vs Monotone","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2008-08-01T09:57:53Z","receivedAt":"2008-08-01T09:57:53Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 31 Jul 2008, Craig L. Ching wrote:\n>> \n>> It's possible he's doing that, but it's also possible he just isn't that\n>> familiar with git.\n>\n> Possible. But it really sounded like he didn't even try. Because quite \n> frankly, if he had even bothered to _try_, he wouldn't have gotten the \n> numbers he got.\n>\n> The fact is, even without \"-s\", a local clone will do hardlinks for the \n> database.\n\nThat means that git takes up less disk space. It does not mean that it\nlooks like it.\n\nIf you do a df before and afterwards, you'll notice (but that does not\nseem reliable as other changed might happen in the file system). If you\ndo \"du\" into the individual clones, you won't notice it.\n\nIt is quite plausible that he might have tried it, but misinterpreted\nthe results.\n\nIt is a similar situation with size estimates when sparse files are\ninvolved: they may take up less space than what it looks like.\n\n-- \nDavid Kastrup\n"},{"id":"85909","messageId":"alpine.LNX.1.00.0808011344060.19665@iabervon.org","threadId":"14777","inReplyTo":"bd6139dc0808010023r5d44e7a2ke062c9c39dfb865c@mail.gmail.com","subject":"Re: Git vs Monotone","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-08-01T18:00:18Z","receivedAt":"2008-08-01T18:00:18Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 1 Aug 2008, Sverre Rabbelier wrote:\n\n> On Thu, Jul 31, 2008 at 20:13, Sverre Rabbelier wrote:\n> > I just read this blog post [0] in which one of the Pidgin devs sheds\n> > his light on their 'tool choice'. In the post he mentions the\n> > following figures:\n> \n> > [0] http://theflamingbanker.blogspot.com/2008/07/holy-war-of-tool-choice.html\n> \n> I have poked him on #pidgin, and he has added the following:\n> \n> \"Note: It's come to my attention that I had missed the ability to\n> share a git database across multiple working copies. In that scenario,\n> the total size of the database and 11 working copies is slightly under\n> 750 MB, and thus a space savings in the neighborhood of 150 MB over\n> monotone. It had been my understanding that I needed a copy of the\n> database per working copy. I stand corrected. I don't use git on a\n> daily basis, as the projects I work with currently use CVS, SVN, or\n> monotone, so I am bound to miss finer details of git here and there.\n> There are other reasons I prefer to stick with monotone, but I won't\n> get into them here, as they're not important to the point of this\n> post.\"\n\nDid he retry the size calculation? I think someone on the list tried it \nand found that the clone, including the checkout, was (for them) the size \nthat he thought was just the database; if you're used to having the clone \nequivalent be effectively --bare by default, it's an easy mistake, \nespecially if you don't think it's possible for the entire project history \nto be smaller than a checkout.\n\nNot that it actually matters to the comparison of monotone and SVN that \nwas the actual point, but still, git is often more space-efficient than \nSVN even just on the client, even without any sharing between branches, \njust because uncompressed source is (relatively) huge. Which does, in a \nway, contribute to the point that SVN have a vast quantity of per-branch\noverhead.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"86722","messageId":"200808110015.41258.robin.rosenberg.lists@dewire.com","threadId":"14777","inReplyTo":"8778C923356C6541B263428246AE9C2A4FE2966B09@NA-MAIL-2-2.rws.ad.ea.com","subject":"Re: Git vs Monotone","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-08-10T22:15:40Z","receivedAt":"2008-08-10T22:15:40Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdagen den 31 juli 2008 22.42.08 skrev Blum, Robert:\n> \n> >The fact is, even without \"-s\", a local clone will do hardlinks for the\n> >database. And since the original pack-file is marked as a 'keep' file,\n> >that original pack-file won't even be broken apart.\n> \n> Then again, Pidgin is, among other things, a Windows project. I.e. hardlinks are not exactly trivial. There's a good chance nobody jumped through the hoops of junction points for git on win32... (Somebody correct me if I'm wrong)\n\nWindows does hardlinks for files since NT 3.51 on NTFS. Cygwin supports it too. Symbolic links are another story. \n\n-- robin\n"},{"id":"88308","messageId":"94a0d4530808231223g5940b691r41072b1432e9c6ab@mail.gmail.com","threadId":"14777","inReplyTo":"7vmyjxyf7a.fsf@gitster.siamese.dyndns.org","subject":"Re: Git vs Monotone","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-23T19:23:06Z","receivedAt":"2008-08-23T19:23:06Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jul 31, 2008 at 11:24 PM, Junio C Hamano wrote:\n> Linus Torvalds writes:\n>\n>> ... And since the original pack-file is marked as a 'keep' file,\n>> that original pack-file won't even be broken apart.\n>\n> Oops, isn't that something we fixed recently as a \"bug\"?\n>\n>> So completely ignoring the fact that you could do a single database with\n>> git, and completely ignoring the fact that with git you'd probably use\n>> branches for at least some of those 11 repos anyway, he'd _still_ have had\n>> less disk space used by git unless he would do something intentionally odd\n>> (like clone all the repositories over the network separately).\n>\n> Well, people are not perfect and they are free to express their opinions\n> based on faulty understanding of reality on their blogs. The right things\n> to do are (1) ignore them on the list and not waste many people's time,\n> and/or (2) educate them, but in private or in a circle where many other\n> similar ignorants benefit from such education. That is not here but\n> perhaps on #monotone channel?\n\nHm, joined late to the discussion.\n\nI had a lengthy discussion on pidgin's mailing list regarding my\nanalysis of monotone [1]. I didn't go very well. I don't think they\nwant to be educated about git.\n\nIt turns out they evaluated git as an option in the 1.0 days and they\ndisregarded it mainly because of the size of the repo; they didn't run\n'git gc'. I fail to understand why they didn't drop in #git or asked\nin the mailing list. That should tell you enough about their informed\ndecisions.\n\nAnyway, that blog post was probably a way to justify their choice\nafter the discussion. With the added note now there's nothing that\nmakes git a bad choice for them, but surely they will find another\nequally flawed reason.\n\nBest regards.\n\n[1] http://pidgin.im/pipermail/devel/2008-July/006308.html\n\n-- \nFelipe Contreras\n"}]}