Re: Fixing the git-repack replacement gap?

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 18, 2013, 17:17 UTC
Message-ID: <7v8v275oez.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201306181052.50490.mfick@codeaurora.org>

Martin Fick <mfick@codeaurora.org> writes:

Show 8 quoted lines

> ... So, what 
> if we could simply add a dummy object to the file to cause 
> it to deserve a name change?
>
> So the idea would be, have git-repack detect the conflict in 
> filenames and have it repack the new file with an additional 
> dummy (unused) object in it, and then deliver the new file 
> which no longer conflicts.  Would this be possible?

Sounds like a fun exercise. I do not think it breaks anything, and because we have the list of objects to be placed in the resulting pack fairly early in the process, this sequence would be possible:

    (1) enumerate the objects;
    (2) compute the resulting packname;
    (3) notice it is the same as an existing one;
    (4) add another dummy object and go back to (2);
    (5) do the heavy-lifting of delitify;
    (6) write out the resulting pack.

inside pack-objects.

I do not know if the loop between (2) and (4) is the only necessary thing to completely avoid the race you are worrying about, though.