Re: [PATCH 0/5] teach replace objects to sha1_object_info_extended()

[Jeff King <peff@peff.net>]

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