From: Martin Langhoff Date: Tue, 30 May 2006 05:14:08 GMT Subject: Re: [RFC] git-fetch - repack in the background after fetching Message-ID: <46a038f90605292214l241a86b8l31edfab010a38c5f@mail.gmail.com> In-Reply-To: On 5/30/06, Linus Torvalds 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