On 5 Sep 2007, Steven Grimm stated: > Nix wrote: >> Indeed. I repack all our git trees in the middle of the night, and our >> incremental backup script drops .keep files corresponding to every >> existing pack before running the backup. >> >> This is probably a good job for cron :) > > If you are setting up cron jobs to repack multiple git trees, you are > not the kind of novice or casual git user who this proposal would > primarily be aimed at. True enough: but the point is that it was only about three lines of code (a locate and git-gc pipeline). We could just put that in the documentation... ... which people then won't read. Oh well. Sorry for the mindless optimism. > git-gc can leave behind a "last completed" timestamp and we can > suppress the check for excess loose objects until some minimum amount > of time has passed since last git-gc. If that amount is greater than > the interval between your cron jobs, you won't even get any > (measurable) overhead from the detection to see if the warning is > needed. I personally wonder if git-gc shouldn't use a proportional scheme, so that only some packs get repacked, maybe the smallest ones (and when they grow to the same size as the next largest one, the two get repacked into one). This has the singular advantage that you won't have to carefully drop .keep files everywhere or have to worry about your git-gc of 50K of loose objects suddenly deciding to repack 100Mb of packfiles and taking ages. It's probably not hard to implement, but I don't need it because I keep everything packed anyway... - 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
