On 5/30/06, Linus Torvalds <torvalds@xxxxxxxx> 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 - : 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