Re: fetching packs and storing them as packs
- From
- Eran Tromer <git2eran@tromer.org>
- Date
- Oct 26, 2006, 14:45 UTC
- Message-ID
- <4540CA0C.6030300@tromer.org>
- In-Reply-To
- <Pine.LNX.4.64.0610252333540.12418@xanadu.home>
On 2006-10-26 05:44, Nicolas Pitre wrote:
Show 12 quoted lines
> diff --git a/receive-pack.c b/receive-pack.c
> index 1fcf3a9..7f6dc49 100644
> --- a/receive-pack.c
> +++ b/receive-pack.c
> @@ -7,7 +7,7 @@
>
> static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
>
> -static const char *unpacker[] = { "unpack-objects", NULL };
> +static const char *unpacker[] = { "index-pack", "-v", "--stdin", "--fix-thin", NULL };
>
> static int report_status;This creates a race condition w.r.t. "git repack -a -d", similar to the existing race condition between "git fetch --keep" and "git repack -a -d". There's a point in time where the new pack is stored but not yet referenced, and if "git repack -a -d" runs at that point it will eradicate the pack. When the heads are finally updated, you get a corrupted repository.
(That's for the shell implementation of git-repack, at least. I assume the new builtin preserves the old semantics.)
Since people run the supposedly safe "git repack -a -d" on regular basis, this is going to bite.
Eran