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

[Christian Couder <chriscool@tuxfamily.org>]

From: Junio C Hamano <gitster@pobox.com>
>
> Jeff King <peff@peff.net> writes:
> 
>> On Mon, Dec 02, 2013 at 09:52:25AM -0500, Jeff King wrote:
>>
>>> 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.
>>
>> Curious what this would look like, I wrote the patch. If you drop your
>> patches 2 and 3, then your final patch (actually fixing the problem)
>> would look like the one below:
>>
>> We may be getting into bikeshed territory, and I don't feel
>> super-strongly about it, so I won't say anything more. Now we've seen
>> both alternatives, and you or Junio can pick. :)

Thanks for doing that.

I still prefer a flag used by sha1_object_info_extended(),
read_sha1_file_extended() and lookup_replace_object_extended().
I think it is more coherent this way.

> FWIW, I shared that "a little funny" feeling ;-)

Yeah, it's true that I should have renamed the flag.
READ_SHA1_FILE_REPLACE is too much related to the read_sha1_file*()
functions.

As it is related to lookup_replace_object*() functions, what
about LOOKUP_REPLACE_OBJECT?

Thanks,
Christian.