On 2006-10-26 05:44, Nicolas Pitre wrote:
> 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
-
To unsubscribe from this list: 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