On Fri, 18 Jan 2008, Junio C Hamano wrote: > > gfi uses data in a "pack" in two quite different ways. > > A new object is written to an unfinalized pack. Such a pack > already has "struct packed_git" allocated for it and a pointer > to it is held in pack_data. As far as the core part of git > (that is, sha1_file.c) is concerned, however, this pack does not > even exist. It is still not part of packed_git list in > sha1_file.c, and read_sha1_file() will not see objects in it, as > no idx into the packfile exists yet. gfi has a table of objects > in this pack and uses gfi_unpack_entry() function to retrieve > data from it. > > A packfile is finalized in end_packfile(). The pack header and > footer is recomputed, an idx file is written, and the pack is > finally registered. Before that time p->index_data is not even > used for that pack (it is initialized with NULL). Oh, ok. I did try to grep for index_data, and didn't find anything that looked bad, but the incestuous things that fast-import.c does just made me worry - but I was too lazy to really follow it all. It's one of those files I don't think I've ever had anything what-so-ever to do with. > So I do not think "index_data usage" can be incorrect, as there > won't be any index_data usage with unfinalized pack, and the > core part of git would not even have any mmap(2) (nor open fd) > into its idx file before it is finalized. In that case, I think Shawn fixed it all, and we're all good, and it's not just hidden well enough that it "just happens" to work. Linus - 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
