Re: [RFC] git-fetch - repack in the background after fetching

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 30, 2006, 05:14 UTC
Message-ID: <46a038f90605292214l241a86b8l31edfab010a38c5f@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0605292147010.5623@g5.osdl.org>

On 5/30/06, Linus Torvalds <torvalds@osdl.org> wrote:

> Repacking is, but "-d" is not necessarily.

Ok -- strawman knocked down. Next try...

Show 10 quoted lines

> Some long-running (in git terms) git programs will look up the pack-files
> when they start, and if you repack after that, they won't see the new
> pack-file, but they _will_ notice that the unpacked files are no longer
> there, and will be very unhappy indeed.
>
> So the "-d" part really isn't necessarily safe.
>
> Of course, in -practice- you won't likely see this, and the archive itself
> is never corrupted, but concurrent git ops can fail due to it in theory,
> and quite frankly, that's not the kind of SCM I like to use.

Would it be safe to repack -a && sleep 180 && git prune-packed ?

> So either just do "git repack -a", or do things synchronously.

Which I take to mean 'prune synchronously'. So what about...

+
+if test $(git rev-list --unpacked --all | wc -l) -gt 1000
+then
+       echo "Repacking in the background"
+       git prune-packed
+       nice git repack -a -q &
+fi

this would mean that at any given time there's a bit of overlap between packed and unpacked, but will be resolved over repeated commands.

martin