On 5 Sep 2007, Steven Grimm stated:

quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html