On Tue, 3 Jul 2007, Sam Vilain wrote: > Nicolas Pitre wrote: > >> Add an option to git-repack that makes the repack run suitable for > >> running very often. The idea is that packs get given a "generation", > >> and that the number of packs in each generation (except the last one) > >> is bounded. > > > > Please explain again why this should be useful and is worth the > > complexity it brings along. Last time this was discussed I wasn't > > convinced at all, and I'm still not convinced this time either. > > First I think we should establish some common ground. > > 1. Do you agree that some users would want their git repositories to be > "maintenance free"? I'm not so sure. I think it is best to let GIT users know (or the admins on their behalf) how to properly maintain their repository than pretending that it needs no maintenance. GIT is a tool for "developers" after all, not for Aunt Tillie. And even if your developers are completely inept to the point of not wanting to run 'git gc' once a week for example, or once a day if they're otherwise really really productive, I'm sure you can automate some of that maintenance asynchronously from a simple post commit hook or something, based on the output of 'git count-objects -v'. > 2. Do you agree that having thousands of packs would add measurable > overhead? Sure it would, but far less as it used to when we last discussed this since performances in those cases has been improved significantly. And if you end up with thousands of packs in the first place I think you have a more fundamental problem to fix, something that generational repacking would just paper over. Nicolas - 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
