Rather nicely done. I see upto 2/6 are identical to what has
sitting in "pu" for the past few days, modulo some indentation?
I wonder how much testing has this series seen, by the way.
Also, I wonder what happens after 5/6 errors out. It dies and
the caller (typically receive-pack) reports it back, which would
fail the push (and does not update the refs). Retrying in such
a case would probably use the same set of refs on both ends,
resulting in exactly the same pack...
On Wed, 1 Nov 2006, Junio C Hamano wrote:
Rather nicely done. I see upto 2/6 are identical to what has
sitting in "pu" for the past few days, modulo some indentation?
Yes. I just inserted them in the serie as I didn't see them in pu until
a very recent pull.
I wonder how much testing has this series seen, by the way.
It has been tested a bit. At least until it started behaving
correctly for me. There might still be bugs remaining, but nothing that
should screw a repository up. I think it should be good enough for next.
Also, I wonder what happens after 5/6 errors out. It dies and
the caller (typically receive-pack) reports it back, which would
fail the push (and does not update the refs). Retrying in such
a case would probably use the same set of refs on both ends,
resulting in exactly the same pack...
Well, the purpose of 5/6 is to avoid creating a .keep file if it already
exists. This is more a security thing so if you decide to mark one of
your pack with .keep (say an history pack that doesn't need to be
repacked) then you don't want a funny git server to send you the same
pack just for the purpose of overwriting the same .keep file (that could
be removed right away if it ends up being considered as a lock file).
This is made more obvious with 6/6 as the .keep file is not removed if
it was there before. So this is not actually an error if creating a
.keep file fails with EEXIST.
As for index-pack dying, it will be reported the same way as
unpack-objects dying -- no difference there. Of course if it dies on
the first push, it is likely to die on all subsequent pushes since the
condition for that to happen is most probably due to a serious problem
(out of disk space, corruption in the existing objects in the
repository, etc).
The pack is put in place with move_temp_to_file() so if a previous
attempt already stored a pack with the same name before successfully
updating corresponding refs then the old pack will silently be kept
since we know both packs contain the same objects when they have the
same name. When a pack is moved it is always complete so there
shouldn't be any (new) instance of repository corruption in normal
circumbstances even in the presence of index-pack dying.