Jens Axboe <jens.axboe@xxxxxxxxxx> writes: > But the new magic is really beside the point. Doing this 'for you' is > extremely annoying behaviour. I often work on my notebook, so disk is > both slow and battery is precious. I DON'T want gc to run automatically, > EVER. Not on repos I have had going for ages, not on ones I just cloned. > Please bury this silly policy and replace it with a printf() telling me > that I may increase my performance by running git gc. Don't just do it. > git does not know better. Well, earlier, git used to be "kick-ass fast, flexible and powerful if you knew what you are doing, and if you don't, then you are forever lost" type of a system, and I think early adopters even took pride in saying so. Being in the scene myself from early on, I certainly sympathise with that feeling, and sometimes when a newcomer starts making noises about dumbing git down without understanding implications (e.g. hiding or removing the index), I have to resist the urge to say "you need to learn certain new concepts that do not even exist counterparts in earlier crap systems you are used to. If you feel you are confused, that's your problem. Get enlightened first." I rarely say that out loud, to be more diplomatic, though. But judging from the fact that some kernel folks talking about having a 7GB kernel repository, I think supposedly early adoptors may not really know what they are doing, and some automation, if done correctly would be a good thing. Having said that, I am not sure how the auto gc is triggering for your (presumably reasonably well maintained) repository that has only small number of loose objects. I haven't seen auto-gc annoyance myself (and git.git is not the only project I have my git experience with), and Linus also said he hasn't seen breakages. I think we did have a few patches to the area recently and we should not rule out the possibility that we broke the criteria "gc --auto" kicks in. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
