From: Junio C Hamano <gits...@pobox.com>
> Jeff King <p...@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*()
As it is related to lookup_replace_object*() functions, what
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html