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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
-
: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]