On 5/30/06, Linus Torvalds <torvalds@osdl.org> 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 - 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.htmlReceived on Tue May 30 15:14:51 2006
This archive was generated by hypermail 2.1.8 : 2006-05-30 15:15:14 EST