Re: Fixing the git-repack replacement gap?

Martin Fick [off-list ref] writes:

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