{"thread":{"id":"12746","subject":"Re: auto gc again","startedAt":"2008-03-18T18:01:18Z","lastAt":"2008-03-20T17:31:01Z","messageCount":30,"participants":["Linus Torvalds","Jens Axboe","Johannes Schindelin","Nicolas Pitre","Junio C Hamano","Brandon Casey","Teemu Likonen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72375","messageId":"20080318180118.GC17940@kernel.dk","threadId":"12746","inReplyTo":null,"subject":"auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-18T18:01:18Z","receivedAt":"2008-03-18T18:01:18Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"Hi,\n\nCould we please PLEASE kill this auto gc thing? I've complained about\nthis in the past and disabled it through the gc.auto config entry,\nhowever now git seems to be happily auto running gc even with gc.auto=0.\nSo there's probably some new magic I need to know.\n\nBut the new magic is really beside the point. Doing this 'for you' is\nextremely annoying behaviour. I often work on my notebook, so disk is\nboth slow and battery is precious. I DON'T want gc to run automatically,\nEVER. Not on repos I have had going for ages, not on ones I just cloned.\nPlease bury this silly policy and replace it with a printf() telling me\nthat I may increase my performance by running git gc. Don't just do it.\ngit does not know better.\n\n \n-- \nJens Axboe\n"},{"id":"72363","messageId":"alpine.LFD.1.00.0803181112270.3020@woody.linux-foundation.org","threadId":"12746","inReplyTo":"20080318180118.GC17940@kernel.dk","subject":"Re: auto gc again","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-18T18:14:14Z","receivedAt":"2008-03-18T18:14:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Mar 2008, Jens Axboe wrote:\n> \n> Could we please PLEASE kill this auto gc thing? I've complained about\n> this in the past and disabled it through the gc.auto config entry,\n> however now git seems to be happily auto running gc even with gc.auto=0.\n> So there's probably some new magic I need to know.\n\nDo you do something odd with your repositories? I don't even touch autogc \non my systems, but I have never had that thing trigger, even when I apply \nseries of patches from Andrew with hundreds of messages.\n\nSo what is it that you do to even get this behaviour in the first place?\n\n\t\t\tLinus\n"},{"id":"72377","messageId":"20080318181948.GH17940@kernel.dk","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803181112270.3020@woody.linux-foundation.org","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-18T18:19:48Z","receivedAt":"2008-03-18T18:19:48Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Tue, Mar 18 2008, Linus Torvalds wrote:\n> \n> \n> On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > \n> > Could we please PLEASE kill this auto gc thing? I've complained about\n> > this in the past and disabled it through the gc.auto config entry,\n> > however now git seems to be happily auto running gc even with gc.auto=0.\n> > So there's probably some new magic I need to know.\n> \n> Do you do something odd with your repositories? I don't even touch autogc \n> on my systems, but I have never had that thing trigger, even when I apply \n> series of patches from Andrew with hundreds of messages.\n\nNot to my knowledge, I haven't changed anything in my setup or behaviour\nin ages.\n\n> So what is it that you do to even get this behaviour in the first place?\n\nThe last few times it was:\n\n$ git checkout master\n$ git branch some-test-branch\n$ git checkout some-test-branch\n$ git pull . some-devel-branch\n\nand after that pull, I get to sit around waiting git gc. Well I don't\nsince I ctrl-c it because it's inconvenient.\n\nBut freshly pulled repo, git auto gc is enabled. And that is my main\nannoyance, I just don't think that type of policy should be in there.\nPrint the warning, include info on how to run git gc or even how to turn\nit on automatically. But I'll bet you that most users will NOT want auto\ngc. Ever.\n\n-- \nJens Axboe\n"},{"id":"72374","messageId":"20080318182421.GI17940@kernel.dk","threadId":"12746","inReplyTo":"20080318181948.GH17940@kernel.dk","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-18T18:24:21Z","receivedAt":"2008-03-18T18:24:21Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Tue, Mar 18 2008, Jens Axboe wrote:\n> On Tue, Mar 18 2008, Linus Torvalds wrote:\n> > \n> > \n> > On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > > \n> > > Could we please PLEASE kill this auto gc thing? I've complained about\n> > > this in the past and disabled it through the gc.auto config entry,\n> > > however now git seems to be happily auto running gc even with gc.auto=0.\n> > > So there's probably some new magic I need to know.\n> > \n> > Do you do something odd with your repositories? I don't even touch autogc \n> > on my systems, but I have never had that thing trigger, even when I apply \n> > series of patches from Andrew with hundreds of messages.\n> \n> Not to my knowledge, I haven't changed anything in my setup or behaviour\n> in ages.\n> \n> > So what is it that you do to even get this behaviour in the first place?\n> \n> The last few times it was:\n> \n> $ git checkout master\n> $ git branch some-test-branch\n> $ git checkout some-test-branch\n> $ git pull . some-devel-branch\n\naxboe@carl:~/git/linux-2.6-block> git count-objects\n901 objects, 6448 kilobytes\n\nxboe@carl:~/git/linux-2.6-block> git pull\nremote: Counting objects: 320, done.\nremote: Compressing objects: 100% (43/43), done.\nremote: Total 214 (delta 171), reused 214 (delta 171)\nReceiving objects: 100% (214/214), 31.78 KiB, done.\nResolving deltas: 100% (171/171), completed with 68 local objects.\nFrom ssh://git.kernel.dk/data/git/linux-2.6-block\n bde4f8f..f920bb6 master -> origin/master\nUpdating bde4f8f..f920bb6\nFast forward\nAuto packing your repository for optimum performance. You may also\nrun \"git gc\" manually. See \"git help gc\" for more information.\n^C\n\nSo 901 objects, pulled 68 objects. And auto gc kicks in. WTF? The git\nbefore was from probably a week ago, this above run was done with git\njust updated.\n\ngit version 1.5.5.rc0.6.gdeda\n\n-- \nJens Axboe\n"},{"id":"72362","messageId":"alpine.LFD.1.00.0803181130240.3020@woody.linux-foundation.org","threadId":"12746","inReplyTo":"20080318182421.GI17940@kernel.dk","subject":"Re: auto gc again","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-18T18:33:45Z","receivedAt":"2008-03-18T18:33:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Mar 2008, Jens Axboe wrote:\n> \n> axboe@carl:~/git/linux-2.6-block> git count-objects\n> 901 objects, 6448 kilobytes\n\nThe default auto-gc threshold is 6700 objects. You should *not* be even \nclose to hitting it.\n\nBut there's a 20-pack pack-limit. Do you have lots of pack-files? But you \ncan disable that one with\n\n\t[gc]\n\t\tautopacklimit = 0\n\nand I do think the default might be a bit low.\n\n\t\tLinus\n"},{"id":"72372","messageId":"20080318183906.GL17940@kernel.dk","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803181130240.3020@woody.linux-foundation.org","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-18T18:39:07Z","receivedAt":"2008-03-18T18:39:07Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Tue, Mar 18 2008, Linus Torvalds wrote:\n> \n> \n> On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > \n> > axboe@carl:~/git/linux-2.6-block> git count-objects\n> > 901 objects, 6448 kilobytes\n> \n> The default auto-gc threshold is 6700 objects. You should *not* be even \n> close to hitting it.\n> \n> But there's a 20-pack pack-limit. Do you have lots of pack-files? But you \n> can disable that one with\n> \n> \t[gc]\n> \t\tautopacklimit = 0\n> \n> and I do think the default might be a bit low.\n\nI let gc run last time to get rid of the complaint, so I cannot answer\nthat question. It's probably the pack limit if that is newer, since the\nobject count was so low.\n\nBut you never answer the question on whether you really consider any\nform of autopacking or auto gc sane? Next time some other limit is added\nfor auto gc, it'll be annoying once more.\n\n-- \nJens Axboe\n"},{"id":"72390","messageId":"alpine.LSU.1.00.0803192121090.3983@racer.site","threadId":"12746","inReplyTo":"20080318183906.GL17940@kernel.dk","subject":"Re: auto gc again","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-19T20:22:24Z","receivedAt":"2008-03-19T20:22:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Mar 2008, Jens Axboe wrote:\n\n> But you never answer the question on whether you really consider any \n> form of autopacking or auto gc sane? Next time some other limit is added \n> for auto gc, it'll be annoying once more.\n\nThe problem is: if people do not bother to \"git gc\" their repositories, \ngit operations get slow. We just had enough of that, and decided to \"git \ngc\" automatically for people who did not know about it, or were to lazy \nand then complained about git for being slow.\n\nHth,\nDscho\n"},{"id":"72397","messageId":"alpine.LFD.1.00.0803191629240.2947@xanadu.home","threadId":"12746","inReplyTo":"20080318181948.GH17940@kernel.dk","subject":"Re: auto gc again","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-19T20:37:29Z","receivedAt":"2008-03-19T20:37:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 18 Mar 2008, Jens Axboe wrote:\n\n> But freshly pulled repo, git auto gc is enabled. And that is my main\n> annoyance, I just don't think that type of policy should be in there.\n\nJust do this once:\n\n\tgit config --global gc.auto 0\n\tgit config --global gc.autopacklimit 0\n\nand be happy.\n\n> Print the warning, include info on how to run git gc or even how to turn\n> it on automatically. But I'll bet you that most users will NOT want auto\n> gc. Ever.\n\nUnfortunately, the harshest complaints about this whole issue were the \nopposite.\n\n\nNicolas\n"},{"id":"72405","messageId":"20080319211436.GC17940@kernel.dk","threadId":"12746","inReplyTo":"alpine.LSU.1.00.0803192121090.3983@racer.site","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-19T21:14:36Z","receivedAt":"2008-03-19T21:14:36Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Wed, Mar 19 2008, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 18 Mar 2008, Jens Axboe wrote:\n> \n> > But you never answer the question on whether you really consider any \n> > form of autopacking or auto gc sane? Next time some other limit is added \n> > for auto gc, it'll be annoying once more.\n> \n> The problem is: if people do not bother to \"git gc\" their repositories, \n> git operations get slow. We just had enough of that, and decided to \"git \n> gc\" automatically for people who did not know about it, or were to lazy \n> and then complained about git for being slow.\n\nSorry I disagree, it's policy and that is usually a bad thing. In this\ncase it definitely is.\n\n-- \nJens Axboe\n"},{"id":"72406","messageId":"20080319211733.GD17940@kernel.dk","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803191629240.2947@xanadu.home","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-19T21:17:34Z","receivedAt":"2008-03-19T21:17:34Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Wed, Mar 19 2008, Nicolas Pitre wrote:\n> On Tue, 18 Mar 2008, Jens Axboe wrote:\n> \n> > But freshly pulled repo, git auto gc is enabled. And that is my main\n> > annoyance, I just don't think that type of policy should be in there.\n> \n> Just do this once:\n> \n> \tgit config --global gc.auto 0\n> \tgit config --global gc.autopacklimit 0\n> \n> and be happy.\n\nYou don't get it. I did gc.auto 0. And know some other limit crops up, I\nhave to do gc.autopacklimit 0. I have LOTS of git trees. On many\nmachines. It's just annoying, period.\n\n> > Print the warning, include info on how to run git gc or even how to turn\n> > it on automatically. But I'll bet you that most users will NOT want auto\n> > gc. Ever.\n> \n> Unfortunately, the harshest complaints about this whole issue were the \n> opposite.\n\nI just don't buy that, I have more faith in users. If they come around\nand complain it's slow, heck you told them it would be.\n\nBut it's not a big deal, I'll just carry a local patch that disables\nthis crap and forget the whole deal. I just worry that if this is where\ngit 'usability' is heading, it wont be a good thing in the long run.\n\n-- \nJens Axboe\n"},{"id":"72411","messageId":"7vd4pq2ymo.fsf@gitster.siamese.dyndns.org","threadId":"12746","inReplyTo":"20080318180118.GC17940@kernel.dk","subject":"Re: auto gc again","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-19T21:27:11Z","receivedAt":"2008-03-19T21:27:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Axboe writes:\n\n> But the new magic is really beside the point. Doing this 'for you' is\n> extremely annoying behaviour. I often work on my notebook, so disk is\n> both slow and battery is precious. I DON'T want gc to run automatically,\n> EVER. Not on repos I have had going for ages, not on ones I just cloned.\n> Please bury this silly policy and replace it with a printf() telling me\n> that I may increase my performance by running git gc. Don't just do it.\n> git does not know better.\n\nWell, earlier, git used to be \"kick-ass fast, flexible and powerful if you\nknew what you are doing, and if you don't, then you are forever lost\" type\nof a system, and I think early adopters even took pride in saying so.\n\nBeing in the scene myself from early on, I certainly sympathise with that\nfeeling, and sometimes when a newcomer starts making noises about dumbing\ngit down without understanding implications (e.g. hiding or removing the\nindex), I have to resist the urge to say \"you need to learn certain new\nconcepts that do not even exist counterparts in earlier crap systems you\nare used to. If you feel you are confused, that's your problem. Get\nenlightened first.\" I rarely say that out loud, to be more diplomatic,\nthough.\n\nBut judging from the fact that some kernel folks talking about having a\n7GB kernel repository, I think supposedly early adoptors may not really\nknow what they are doing, and some automation, if done correctly would be\na good thing.\n\nHaving said that, I am not sure how the auto gc is triggering for your\n(presumably reasonably well maintained) repository that has only small\nnumber of loose objects. I haven't seen auto-gc annoyance myself (and\ngit.git is not the only project I have my git experience with), and Linus\nalso said he hasn't seen breakages.\n\nI think we did have a few patches to the area recently and we should not\nrule out the possibility that we broke the criteria \"gc --auto\" kicks in.\n"},{"id":"72414","messageId":"47E18540.4020908@nrlssc.navy.mil","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803191629240.2947@xanadu.home","subject":"Re: auto gc again","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-03-19T21:27:28Z","receivedAt":"2008-03-19T21:27:28Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Nicolas Pitre wrote:\n> On Tue, 18 Mar 2008, Jens Axboe wrote:\n> \n>> But freshly pulled repo, git auto gc is enabled. And that is my main\n>> annoyance, I just don't think that type of policy should be in there.\n> \n> Just do this once:\n> \n> \tgit config --global gc.auto 0\n> \tgit config --global gc.autopacklimit 0\n\nIs there any reason why gc.auto=0 couldn't be used to disable auto\npacking entirely?\n\nSaid differently, are there valid use cases where one might want automatic\nrepacking based on the number of packs but _not_ based on the number of\nloose objects?\n\nIf the answer is \"no\", then \"gc.auto=0 means completely disable auto-gc\"\nseems intuitive and would have protected Jens in this case.\n\n-brandon\n"},{"id":"72417","messageId":"alpine.LSU.1.00.0803192243270.3983@racer.site","threadId":"12746","inReplyTo":"20080319211436.GC17940@kernel.dk","subject":"Re: auto gc again","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-19T21:44:20Z","receivedAt":"2008-03-19T21:44:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 19 Mar 2008, Jens Axboe wrote:\n\n> On Wed, Mar 19 2008, Johannes Schindelin wrote:\n> \n> > On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > \n> > > But you never answer the question on whether you really consider any \n> > > form of autopacking or auto gc sane? Next time some other limit is \n> > > added for auto gc, it'll be annoying once more.\n> > \n> > The problem is: if people do not bother to \"git gc\" their \n> > repositories, git operations get slow. We just had enough of that, \n> > and decided to \"git gc\" automatically for people who did not know \n> > about it, or were to lazy and then complained about git for being \n> > slow.\n> \n> Sorry I disagree,\n\nIn this case, you can disagree as much as you want and you are still \nwrong.\n\nThe problem is that you are more intelligent than most others, and now you \nexperience the downsides of it.\n\nCiao,\nDscho\n"},{"id":"72419","messageId":"alpine.LFD.1.00.0803191444490.3020@woody.linux-foundation.org","threadId":"12746","inReplyTo":"7vd4pq2ymo.fsf@gitster.siamese.dyndns.org","subject":"Re: auto gc again","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-19T21:52:14Z","receivedAt":"2008-03-19T21:52:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Mar 2008, Junio C Hamano wrote:\n> \n> Having said that, I am not sure how the auto gc is triggering for your\n> (presumably reasonably well maintained) repository that has only small\n> number of loose objects. I haven't seen auto-gc annoyance myself (and\n> git.git is not the only project I have my git experience with), and Linus\n> also said he hasn't seen breakages.\n\nI think it was 'autopacklimit'.\n\nI think the correct solution is along the following lines:\n\n - disable \"git gc --auto\" entirely when \"gc.auto <= 0\" (ie we don't even \n care about 'autopacklimit' unless automatic packing is on at all)\n\n Rationale: I do think that if you set gc.auto to zero, you should \n expect git gc --auto to be disabled.\n\n - make the default for autopacklimit rather higher (pick number at \n random: 50 instead of 20).\n\n Rationale: the reason for \"git gc --auto\" wasn't to keep things \n perfectly packed, but to avoid the _really_ bad cases. The old default \n of 20 may be fine if you want to always keep the repo very tight, but \n that wasn't why \"git gc --auto\" was done, was it?\n\nSuggested patch appended. Comments?\n\n\t\tLinus\n---\n builtin-gc.c | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-gc.c b/builtin-gc.c\nindex 95917d7..16a912a 100644\n--- a/builtin-gc.c\n+++ b/builtin-gc.c\n@@ -25,7 +25,7 @@ static const char * const builtin_gc_usage[] = {\n static int pack_refs = 1;\n static int aggressive_window = -1;\n static int gc_auto_threshold = 6700;\n-static int gc_auto_pack_limit = 20;\n+static int gc_auto_pack_limit = 50;\n static char *prune_expire = \"2.weeks.ago\";\n \n #define MAX_ADD 10\n@@ -163,7 +163,7 @@ static int need_to_gc(void)\n \t * Setting gc.auto and gc.autopacklimit to 0 or negative can\n \t * disable the automatic gc.\n \t */\n-\tif (gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0)\n+\tif (gc_auto_threshold <= 0)\n \t\treturn 0;\n \n \t/*\n"},{"id":"72420","messageId":"47E18B50.2080402@nrlssc.navy.mil","threadId":"12746","inReplyTo":"47E18540.4020908@nrlssc.navy.mil","subject":"[PATCH] builtin-gc.c: allow disabling all auto-gc'ing by assigning 0 to gc.auto","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-03-19T21:53:20Z","receivedAt":"2008-03-19T21:53:20Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"The gc.auto configuration variable is somewhat ambiguous now that there\nis also a gc.autopacklimit setting. Some users may assume that it controls\nall auto-gc'ing. Also, now users must set two configuration variables to\nzero when they want to disable autopacking. Since it is unlikely that users\nwill want to autopack based on some threshold of pack files when they have\ndisabled autopacking based on the number of loose objects, be nice and allow\na setting of zero for gc.auto to disable all autopacking.\n\nSigned-off-by: Brandon Casey \n---\n builtin-gc.c | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-gc.c b/builtin-gc.c\nindex 95917d7..509bb9c 100644\n--- a/builtin-gc.c\n+++ b/builtin-gc.c\n@@ -160,10 +160,10 @@ static int too_many_packs(void)\n static int need_to_gc(void)\n {\n \t/*\n-\t * Setting gc.auto and gc.autopacklimit to 0 or negative can\n-\t * disable the automatic gc.\n+\t * Setting gc.auto to 0 or negative can disable the\n+\t * automatic gc.\n \t */\n-\tif (gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0)\n+\tif (gc_auto_threshold <= 0)\n \t\treturn 0;\n \n \t/*\n-- \n1.5.4.4.481.g5075\n"},{"id":"72428","messageId":"7vod9a1h8e.fsf@gitster.siamese.dyndns.org","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803191444490.3020@woody.linux-foundation.org","subject":"Re: auto gc again","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-19T22:28:17Z","receivedAt":"2008-03-19T22:28:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Wed, 19 Mar 2008, Junio C Hamano wrote:\n>> \n>> Having said that, I am not sure how the auto gc is triggering for your\n>> (presumably reasonably well maintained) repository that has only small\n>> number of loose objects. I haven't seen auto-gc annoyance myself (and\n>> git.git is not the only project I have my git experience with), and Linus\n>> also said he hasn't seen breakages.\n>\n> I think it was 'autopacklimit'.\n>\n> I think the correct solution is along the following lines:\n>\n> - disable \"git gc --auto\" entirely when \"gc.auto <= 0\" (ie we don't even \n> care about 'autopacklimit' unless automatic packing is on at all)\n>\n> Rationale: I do think that if you set gc.auto to zero, you should \n> expect git gc --auto to be disabled.\n\nSensible, I would say.\n\n> - make the default for autopacklimit rather higher (pick number at \n> random: 50 instead of 20).\n>\n> Rationale: the reason for \"git gc --auto\" wasn't to keep things \n> perfectly packed, but to avoid the _really_ bad cases. The old default \n> of 20 may be fine if you want to always keep the repo very tight, but \n> that wasn't why \"git gc --auto\" was done, was it?\n\nI do not think \"very tight\" was the reason, but on the other hand, my\npersonal feeling is that 20 was already 10 too many pack idx files we have\nto walk linearly while looking for objects at runtime.\n\nEach auto gc that sees too many loose objects will add a new packfile (we\ndo not do \"repack -a\" for obvious reasons) that would hopefully contain\n6-7k objects, so you would need to generate 120-140k objects before\nhitting the existing 20 limit.\n\nAnd then auto gc will notice you have too many packs, and \"repack -A\" to\npack them down in a single new pack, and you are back to \"single pack with\nless than 6-7k loose objects\" situation for the cycle to continue.\n\nAt least, that is the theory.\n\nThe kernel history with 87k commits have 720k objects, which roughly\ntranslates to 8 objects per commit on average. You would need to perform\n13k commits to generate 100k new loose objects. I am sensing that Jens is\nmightily annoyed, rightfully so, by observing much shorter cycle than that\nfor \"gc --auto\" to kick in (\"rev-list --author=Jens --since=8.month master\"\ntells me there are 145 commits in the last 8 months, far smaller than\n13k). So there is something else going on.\n\nPerhaps fetching with dumb transports should run \"gc --auto\" (or even an\nunconditional \"repack -a -d\") at the end?\n"},{"id":"72438","messageId":"alpine.LFD.1.00.0803191855030.2947@xanadu.home","threadId":"12746","inReplyTo":"47E18540.4020908@nrlssc.navy.mil","subject":"Re: auto gc again","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-19T22:56:20Z","receivedAt":"2008-03-19T22:56:20Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 19 Mar 2008, Brandon Casey wrote:\n\n> Nicolas Pitre wrote:\n> > On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > \n> >> But freshly pulled repo, git auto gc is enabled. And that is my main\n> >> annoyance, I just don't think that type of policy should be in there.\n> > \n> > Just do this once:\n> > \n> > \tgit config --global gc.auto 0\n> > \tgit config --global gc.autopacklimit 0\n> \n> Is there any reason why gc.auto=0 couldn't be used to disable auto\n> packing entirely?\n\nI think that would be a good thing to do indeed.\n\n> Said differently, are there valid use cases where one might want automatic\n> repacking based on the number of packs but _not_ based on the number of\n> loose objects?\n> \n> If the answer is \"no\", then \"gc.auto=0 means completely disable auto-gc\"\n> seems intuitive and would have protected Jens in this case.\n\nAgreed.\n\n\nNicolas\n"},{"id":"72440","messageId":"alpine.LFD.1.00.0803191856290.2947@xanadu.home","threadId":"12746","inReplyTo":"20080319211733.GD17940@kernel.dk","subject":"Re: auto gc again","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-19T23:05:37Z","receivedAt":"2008-03-19T23:05:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 19 Mar 2008, Jens Axboe wrote:\n\n> On Wed, Mar 19 2008, Nicolas Pitre wrote:\n> > On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > \n> > > But freshly pulled repo, git auto gc is enabled. And that is my main\n> > > annoyance, I just don't think that type of policy should be in there.\n> > \n> > Just do this once:\n> > \n> > \tgit config --global gc.auto 0\n> > \tgit config --global gc.autopacklimit 0\n> > \n> > and be happy.\n> \n> You don't get it. I did gc.auto 0. And know some other limit crops up, I\n> have to do gc.autopacklimit 0. I have LOTS of git trees. On many\n> machines. It's just annoying, period.\n\nAs suggested, gc.auto = 0 should probably be made to disable it \nentirely, regardless of any other parameters that might exist.\n\n> > > Print the warning, include info on how to run git gc or even how to turn\n> > > it on automatically. But I'll bet you that most users will NOT want auto\n> > > gc. Ever.\n> > \n> > Unfortunately, the harshest complaints about this whole issue were the \n> > opposite.\n> \n> I just don't buy that, I have more faith in users.\n\nWe also did in the past... even for a long period...\n\nAlas, it is the users who made us (and actually made Linus, who was the \nlast to resist) change our minds.\n\n> If they come around and complain it's slow, heck you told them it \n> would be.\n\nBut they don't. They just presume that Git is crap and move on.\n\n> But it's not a big deal, I'll just carry a local patch that disables\n> this crap and forget the whole deal. I just worry that if this is where\n> git 'usability' is heading, it wont be a good thing in the long run.\n\nI wish the majority of users was thinking like you. I, too, have some \nconceptual problems with this auto gc things. With the experience \nwe've gathered, the current state appears to be the \nlesser of all evils though.\n\n\nNicolas\n"},{"id":"72441","messageId":"alpine.LFD.1.00.0803191910170.2947@xanadu.home","threadId":"12746","inReplyTo":"7vod9a1h8e.fsf@gitster.siamese.dyndns.org","subject":"Re: auto gc again","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-19T23:16:15Z","receivedAt":"2008-03-19T23:16:15Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 19 Mar 2008, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > On Wed, 19 Mar 2008, Junio C Hamano wrote:\n> >> \n> >> Having said that, I am not sure how the auto gc is triggering for your\n> >> (presumably reasonably well maintained) repository that has only small\n> >> number of loose objects. I haven't seen auto-gc annoyance myself (and\n> >> git.git is not the only project I have my git experience with), and Linus\n> >> also said he hasn't seen breakages.\n> >\n> > I think it was 'autopacklimit'.\n> >\n> > I think the correct solution is along the following lines:\n> >\n> > - disable \"git gc --auto\" entirely when \"gc.auto <= 0\" (ie we don't even \n> > care about 'autopacklimit' unless automatic packing is on at all)\n> >\n> > Rationale: I do think that if you set gc.auto to zero, you should \n> > expect git gc --auto to be disabled.\n> \n> Sensible, I would say.\n\nSeconded.\n\n> > - make the default for autopacklimit rather higher (pick number at \n> > random: 50 instead of 20).\n> >\n> > Rationale: the reason for \"git gc --auto\" wasn't to keep things \n> > perfectly packed, but to avoid the _really_ bad cases. The old default \n> > of 20 may be fine if you want to always keep the repo very tight, but \n> > that wasn't why \"git gc --auto\" was done, was it?\n> \n> I do not think \"very tight\" was the reason, but on the other hand, my\n> personal feeling is that 20 was already 10 too many pack idx files we have\n> to walk linearly while looking for objects at runtime.\n\nSince commit f7c22cc68ccb this is no longer such an issue.\n\n> Each auto gc that sees too many loose objects will add a new packfile (we\n> do not do \"repack -a\" for obvious reasons) that would hopefully contain\n> 6-7k objects, so you would need to generate 120-140k objects before\n> hitting the existing 20 limit.\n> \n> And then auto gc will notice you have too many packs, and \"repack -A\" to\n> pack them down in a single new pack, and you are back to \"single pack with\n> less than 6-7k loose objects\" situation for the cycle to continue.\n> \n> At least, that is the theory.\n\nNote that the current fetch.unpackLimit might play a role as well, \nespecially if you fetch often (often meaning that you're more likely to \nhave the received pack exploded into loose objects, or you're \naccumulating many small packs).\n\n\nNicolas\n"},{"id":"72442","messageId":"7vd4pq1el3.fsf@gitster.siamese.dyndns.org","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803191910170.2947@xanadu.home","subject":"Re: auto gc again","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-19T23:25:28Z","receivedAt":"2008-03-19T23:25:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 19 Mar 2008, Junio C Hamano wrote:\n>\n>> Linus Torvalds writes:\n>> \n>> > On Wed, 19 Mar 2008, Junio C Hamano wrote:\n>> ...\n>> > - make the default for autopacklimit rather higher (pick number at \n>> > random: 50 instead of 20).\n>> >\n>> > Rationale: the reason for \"git gc --auto\" wasn't to keep things \n>> > perfectly packed, but to avoid the _really_ bad cases. The old default \n>> > of 20 may be fine if you want to always keep the repo very tight, but \n>> > that wasn't why \"git gc --auto\" was done, was it?\n>> \n>> I do not think \"very tight\" was the reason, but on the other hand, my\n>> personal feeling is that 20 was already 10 too many pack idx files we have\n>> to walk linearly while looking for objects at runtime.\n>\n> Since commit f7c22cc68ccb this is no longer such an issue.\n\nNotice that I did not say \"19 too many\". I know f7c22cc (always start\nlooking up objects in the last used pack first, 2007-05-30) was meant to\nalleviate the situation, but isn't \"no longer\" a gross exaggeration?\n\n> Note that the current fetch.unpackLimit might play a role as well, \n> especially if you fetch often (often meaning that you're more likely to \n> have the received pack exploded into loose objects, or you're \n> accumulating many small packs).\n\nAh, yes, native fetch will also result in a new pack, so even if you do\nnot do anything else, if you fetch once a day, you will accumulate 20\npacks in that many days.\n"},{"id":"72473","messageId":"alpine.LFD.1.00.0803192228260.2947@xanadu.home","threadId":"12746","inReplyTo":"7vd4pq1el3.fsf@gitster.siamese.dyndns.org","subject":"Re: auto gc again","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-20T03:13:52Z","receivedAt":"2008-03-20T03:13:52Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 19 Mar 2008, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> >On Wed, 19 Mar 2008, Junio C Hamano wrote:\n> >\n> >> I do not think \"very tight\" was the reason, but on the other hand, my\n> >> personal feeling is that 20 was already 10 too many pack idx files we have\n> >> to walk linearly while looking for objects at runtime.\n> >\n> > Since commit f7c22cc68ccb this is no longer such an issue.\n> \n> Notice that I did not say \"19 too many\". I know f7c22cc (always start\n> looking up objects in the last used pack first, 2007-05-30) was meant to\n> alleviate the situation, but isn't \"no longer\" a gross exaggeration?\n\nNot at all. Please have a second look at the performance numbers in \nthat commit log, and take into accound the most important metric that I \nunfortunately failed to mention there (although I subsequently posted it \nto the list: http://marc.info/?l=git&m=118058197921642&w=2), wich is the \ntime to perform the same operation with a single pack.\n\nSo you have 17.1 seconds for a single pack vs 18.4 seconds for 66 packs.\n\nCompare that to 24.9s without that patch.\n\nAnd I still have some further optimizations to implement eventually \n(http://marc.info/?l=git&m=118062793413099&w=2), but which would \nprobably make a significant difference only in the hundreds-of-packs \ncase anyway.\n\nSo I really think that the default gc.autopacklimit could be raised.\n\n\nNicolas\n"},{"id":"72475","messageId":"7vfxumyr2r.fsf@gitster.siamese.dyndns.org","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803192228260.2947@xanadu.home","subject":"Re: auto gc again","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-20T04:09:16Z","receivedAt":"2008-03-20T04:09:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> So you have 17.1 seconds for a single pack vs 18.4 seconds for 66 packs.\n>\n> Compare that to 24.9s without that patch.\n\nVery interesting --- why should it affect a single pack case at all?\n\n> And I still have some further optimizations to implement eventually \n> (http://marc.info/?l=git&m=118062793413099&w=2), but which would \n> probably make a significant difference only in the hundreds-of-packs \n> case anyway.\n>\n> So I really think that the default gc.autopacklimit could be raised.\n\nThanks, let's raise it to 50 then.\n\nBut I am still puzzled...\n"},{"id":"72479","messageId":"alpine.LFD.1.00.0803200030020.2947@xanadu.home","threadId":"12746","inReplyTo":"7vfxumyr2r.fsf@gitster.siamese.dyndns.org","subject":"Re: auto gc again","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-20T04:40:20Z","receivedAt":"2008-03-20T04:40:20Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 19 Mar 2008, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > So you have 17.1 seconds for a single pack vs 18.4 seconds for 66 packs.\n> >\n> > Compare that to 24.9s without that patch.\n> \n> Very interesting --- why should it affect a single pack case at all?\n\nIt is not:\n\nSingle pack = 17.1s\n66 packs with commit f7c22cc6 = 18.4s\n66 packs without commit f7c22cc6 = 24.9s\n\nThe point is that having many packs doesn't impose a significant \noverhead anymore when comparing to the single pack case.\n\n> Thanks, let's raise it to 50 then.\n\nHaving only to set gc.auto=0 to disable it entirely is also a good \nthing.\n\n> But I am still puzzled...\n\nPlease tell me why if this is still the case.\n\n\nNicolas\n"},{"id":"72482","messageId":"7v7ifyyp89.fsf@gitster.siamese.dyndns.org","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803200030020.2947@xanadu.home","subject":"Re: auto gc again","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-20T04:49:10Z","receivedAt":"2008-03-20T04:49:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 19 Mar 2008, Junio C Hamano wrote:\n>\n>> Nicolas Pitre writes:\n>> \n>> > So you have 17.1 seconds for a single pack vs 18.4 seconds for 66 packs.\n>> >\n>> > Compare that to 24.9s without that patch.\n>> \n>> Very interesting --- why should it affect a single pack case at all?\n>\n> It is not:\n>\n> Single pack = 17.1s\n> 66 packs with commit f7c22cc6 = 18.4s\n> 66 packs without commit f7c22cc6 = 24.9s\n> ...\n>> But I am still puzzled...\n>\n> Please tell me why if this is still the case.\n\nNot anymore. Your \"It is not\" above cleared things for me. Somehow I\nmisread \"with patch single pack is 17.1s and even with 66 packs it is only\n18.4s, compare these great numbers with horrible 24.9s with single pack\nwithout the patch\".\n"},{"id":"72486","messageId":"20080320060030.GE17940@kernel.dk","threadId":"12746","inReplyTo":"alpine.LSU.1.00.0803192243270.3983@racer.site","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-20T06:00:32Z","receivedAt":"2008-03-20T06:00:32Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Wed, Mar 19 2008, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 19 Mar 2008, Jens Axboe wrote:\n> \n> > On Wed, Mar 19 2008, Johannes Schindelin wrote:\n> > \n> > > On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > > \n> > > > But you never answer the question on whether you really consider any \n> > > > form of autopacking or auto gc sane? Next time some other limit is \n> > > > added for auto gc, it'll be annoying once more.\n> > > \n> > > The problem is: if people do not bother to \"git gc\" their \n> > > repositories, git operations get slow. We just had enough of that, \n> > > and decided to \"git gc\" automatically for people who did not know \n> > > about it, or were to lazy and then complained about git for being \n> > > slow.\n> > \n> > Sorry I disagree,\n> \n> In this case, you can disagree as much as you want and you are still \n> wrong.\n\nYou are catering to the wrong end of the scale, nothing good comes of\nthat in the longer run.\n\n> The problem is that you are more intelligent than most others, and now you \n> experience the downsides of it.\n\nWhatever. If you don't have something worthwhile to say, please don't\nrespond.\n\n-- \nJens Axboe\n"},{"id":"72487","messageId":"20080320060119.GF17940@kernel.dk","threadId":"12746","inReplyTo":"47E18540.4020908@nrlssc.navy.mil","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-20T06:01:19Z","receivedAt":"2008-03-20T06:01:19Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Wed, Mar 19 2008, Brandon Casey wrote:\n> Nicolas Pitre wrote:\n> > On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > \n> >> But freshly pulled repo, git auto gc is enabled. And that is my main\n> >> annoyance, I just don't think that type of policy should be in there.\n> > \n> > Just do this once:\n> > \n> > \tgit config --global gc.auto 0\n> > \tgit config --global gc.autopacklimit 0\n> \n> Is there any reason why gc.auto=0 couldn't be used to disable auto\n> packing entirely?\n> \n> Said differently, are there valid use cases where one might want automatic\n> repacking based on the number of packs but _not_ based on the number of\n> loose objects?\n> \n> If the answer is \"no\", then \"gc.auto=0 means completely disable auto-gc\"\n> seems intuitive and would have protected Jens in this case.\n\nTotally agree, makes a lot more sense.\n\n-- \nJens Axboe\n"},{"id":"72491","messageId":"200803200908.14061.tlikonen@iki.fi","threadId":"12746","inReplyTo":"47E18B50.2080402@nrlssc.navy.mil","subject":"Re: [PATCH] builtin-gc.c: allow disabling all auto-gc'ing by assigning 0 to gc.auto","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-03-20T07:08:13Z","receivedAt":"2008-03-20T07:08:13Z","isPatch":true,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Brandon Casey kirjoitti:\n\n> The gc.auto configuration variable is somewhat ambiguous now that\n> there is also a gc.autopacklimit setting. Some users may assume that\n> it controls all auto-gc'ing. Also, now users must set two\n> configuration variables to zero when they want to disable\n> autopacking. Since it is unlikely that users will want to autopack\n> based on some threshold of pack files when they have disabled\n> autopacking based on the number of loose objects, be nice and allow a\n> setting of zero for gc.auto to disable all autopacking.\n>\n> Signed-off-by: Brandon Casey \n> ---\n> builtin-gc.c | 6 +++---\n> 1 files changed, 3 insertions(+), 3 deletions(-)\n\nThis change should be documented in the git-gc.txt and config.txt. For \nexample, the former currently says:\n\n\"Housekeeping is required if there are too many loose objects or too \nmany packs in the repository. [...] Setting the value of `gc.auto` to 0 \ndisables automatic packing of loose objects.\"\n\nSo, from the git-gc.txt's (current) point of view, gc.auto=0 does not \ntouch the \"or too many packs\" part.\n"},{"id":"72493","messageId":"20080320074057.GH17940@kernel.dk","threadId":"12746","inReplyTo":"alpine.LFD.1.00.0803191856290.2947@xanadu.home","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-20T07:40:57Z","receivedAt":"2008-03-20T07:40:57Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Wed, Mar 19 2008, Nicolas Pitre wrote:\n> On Wed, 19 Mar 2008, Jens Axboe wrote:\n> \n> > On Wed, Mar 19 2008, Nicolas Pitre wrote:\n> > > On Tue, 18 Mar 2008, Jens Axboe wrote:\n> > > \n> > > > But freshly pulled repo, git auto gc is enabled. And that is my main\n> > > > annoyance, I just don't think that type of policy should be in there.\n> > > \n> > > Just do this once:\n> > > \n> > > \tgit config --global gc.auto 0\n> > > \tgit config --global gc.autopacklimit 0\n> > > \n> > > and be happy.\n> > \n> > You don't get it. I did gc.auto 0. And know some other limit crops up, I\n> > have to do gc.autopacklimit 0. I have LOTS of git trees. On many\n> > machines. It's just annoying, period.\n> \n> As suggested, gc.auto = 0 should probably be made to disable it \n> entirely, regardless of any other parameters that might exist.\n\nYes, agree.\n\n> > > > Print the warning, include info on how to run git gc or even how to turn\n> > > > it on automatically. But I'll bet you that most users will NOT want auto\n> > > > gc. Ever.\n> > > \n> > > Unfortunately, the harshest complaints about this whole issue were the \n> > > opposite.\n> > \n> > I just don't buy that, I have more faith in users.\n> \n> We also did in the past... even for a long period...\n> \n> Alas, it is the users who made us (and actually made Linus, who was the \n> last to resist) change our minds.\n\nOK, that's at least reassuring :-)\n\n> > If they come around and complain it's slow, heck you told them it \n> > would be.\n> \n> But they don't. They just presume that Git is crap and move on.\n\nThat's pretty sad, I like to have high hopes for users.\n\n> > But it's not a big deal, I'll just carry a local patch that disables\n> > this crap and forget the whole deal. I just worry that if this is where\n> > git 'usability' is heading, it wont be a good thing in the long run.\n> \n> I wish the majority of users was thinking like you. I, too, have some \n> conceptual problems with this auto gc things. With the experience \n> we've gathered, the current state appears to be the \n> lesser of all evils though.\n\nAlright, I must bow down to empirical evidence... The conceptual policy\nproblem is indeed what is bothering me so much, even more so than the\nactual gc running on my machine.\n\ngc.auto covering everything is good enough for me, GIT_GC_AUTO\nenvironment variable would be better because of the way that I work. But\nI can get by knowing that the gc.auto thing will at least only bite me\nonce per tree. And perhaps just wrap git clone in one of my scripts\nthat'll then do the gc.auto thing automatically.\n\n-- \nJens Axboe\n"},{"id":"72497","messageId":"7vhcf1ygl4.fsf@gitster.siamese.dyndns.org","threadId":"12746","inReplyTo":"20080320074057.GH17940@kernel.dk","subject":"Re: auto gc again","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-20T07:55:51Z","receivedAt":"2008-03-20T07:55:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Axboe writes:\n\n> gc.auto covering everything is good enough for me, GIT_GC_AUTO\n> environment variable would be better because of the way that I work. But\n> I can get by knowing that the gc.auto thing will at least only bite me\n> once per tree. And perhaps just wrap git clone in one of my scripts\n> that'll then do the gc.auto thing automatically.\n\nYou missed --global part of the suggestion, perhaps?\n"},{"id":"72533","messageId":"20080320173100.GJ17940@kernel.dk","threadId":"12746","inReplyTo":"7vhcf1ygl4.fsf@gitster.siamese.dyndns.org","subject":"Re: auto gc again","fromName":"Jens Axboe","fromEmail":"jens.axboe@oracle.com","sentAt":"2008-03-20T17:31:01Z","receivedAt":"2008-03-20T17:31:01Z","isPatch":false,"sender":{"key":"axboe@kernel.dk","avatar":null},"body":"On Thu, Mar 20 2008, Junio C Hamano wrote:\n> Jens Axboe writes:\n> \n> > gc.auto covering everything is good enough for me, GIT_GC_AUTO\n> > environment variable would be better because of the way that I work. But\n> > I can get by knowing that the gc.auto thing will at least only bite me\n> > once per tree. And perhaps just wrap git clone in one of my scripts\n> > that'll then do the gc.auto thing automatically.\n> \n> You missed --global part of the suggestion, perhaps?\n\nI did indeed, --global does exactly what I meant with GIT_GC_AUTO.\nThanks!\n\n-- \nJens Axboe\n"}]}