On Sat, Nov 30, 2013 at 02:51:18PM +0100, Christian Couder wrote: > Here is a patch series to improve the way sha1_object_info_extended() > behaves when it is passed a replaced object. > [...] > Christian Couder (5): > replace_object: don't check read_replace_refs twice > introduce lookup_replace_object_extended() to pass flags > Add an "unsigned flags" parameter to sha1_object_info_extended() > t6050: show that git cat-file --batch fails with replace objects > sha1_file: perform object replacement in sha1_object_info_extended() Overall looks OK to me. I find it a little funny that we reuse the READ_SHA1_FILE_REPLACE flag directly in lookup_replace_object. That means that it is now a meaningful flag for sha1_object_info_extended, even though the name does not say so. It also means that the two may have to coordinate further flags (since a portion of their flag namespace is shared by lookup_replace_object). I don't foresee adding a lot of new flags, though, so it probably isn't a huge deal. I also would have expected sha1_object_info_extended to simply receive the new flag via the struct object_info. Again, probably not a big deal, because there aren't many callsites that needed updating. But if we were not sharing flags with read_sha1_file, I think doing it as a flag in the struct would be nicer. I checked the resulting behavior against the list I made earlier; looks like all of the _extended callsites are doing the right thing. I do think the checks you added in 277336a (replace: forbid replacing an object with one of a different type, 2013-09-06) need updating. I started on that, but I wonder if all of cmd_replace should simply turn off read_replace_refs. I'd think it would always want to be dealing with the true objects. -Peff -- 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