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

From: Linus Torvalds <torvalds@osdl.org>
Date: May 30, 2006, 04:51 UTC
Message-ID: <Pine.LNX.4.64.0605292147010.5623@g5.osdl.org>
In-Reply-To: <11489641631558-git-send-email-martin@catalyst.net.nz>

On Tue, 30 May 2006, Martin Langhoff wrote:

> 
> There's been some discussion about repacking proactively without
> preventing further work. But as Linus said, repacking on an active
> repo is _safe_

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

You really should do the prune-packed only _after_ you've repacked, and no old git programs are around.

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.

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

		Linus