On Wed, 2 Feb 2011, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxxxxxx> writes: > > >> $ git index-pack > >> .git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.pack > >> Unlink of file '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx' > >> failed. Should I try again? (y/n)? n > >> fatal: unable to create > >> '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx': > >> File exists > > > > Why would you do such thing in the first place? > > > > If the pack exists along with its index on disk, there is no point > > recreating it. Maybe index-pack should just bail out early in that > > case. > > I am trying to see if an index-pack with slight modification would be a > good replacement for verify-pack. OK, then you don't intend to reuse it as is. If you really wanted to have index-pack work in place then you would have to use free_pack_by_name() somewhere before writing the new pack index out, but that is still a dubious use case. index-pack _could_ be a replacement for verify-pack. It certainly can validate a pack since it is its purpose, possibly faster than verify-pack. You'd still have to compare the existing pack index against the one index-pack creates without overwriting that original index, taking into accound index version differences, etc. However index-pack won't tell you what is broken in the pack when corruptions are to be found. It will simply tell you at the very end that the checksum hash doesn't match, or that some deltas were not resolved, that kind of thing, whereas verify-pack has the ability to tell you exactly what doesn't match with the info in the index or the like as soon as it encounters a problem. 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