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

On 5/30/06, Linus Torvalds [off-list ref] wrote:

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

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

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