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*() functions. As it is related to lookup_replace_object*() functions, what about LOOKUP_REPLACE_OBJECT? Thanks, Christian. -- 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
