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