git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Christian Couder <chriscool@tuxfamily.org>
Date
Dec 3, 2013, 20:42 UTC
Message-ID
<20131203.214209.1698497614731424957.chriscool@tuxfamily.org>
In-Reply-To
<xmqqtxeqq0qs.fsf@gitster.dls.corp.google.com>
From: Junio C Hamano <gitster@pobox.com>
Show 26 quoted lines
>
> 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.

Previous: Junio C HamanoNext: Christian Couder
Message 10 of 11 in “teach replace objects to sha1_object_info_extended()”
  1. 0/5 teach replace objects to sha1_object_info_extended()Christian Couder, Nov 30, 2013
  2. 1/5 replace_object: don't check read_replace_refs twiceChristian Couder, Nov 30, 2013
  3. 2/5 introduce lookup_replace_object_extended() to pass flagsChristian Couder, Nov 30, 2013
  4. 3/5 Add an "unsigned flags" parameter to sha1_object_info_extended()Christian Couder, Nov 30, 2013
  5. 4/5 t6050: show that git cat-file --batch fails with replace objectsChristian Couder, Nov 30, 2013
  6. 5/5 sha1_file: perform object replacement in sha1_object_info_extended()Christian Couder, Nov 30, 2013
  7. Jeff KingDec 2, 2013
  8. Jeff KingDec 2, 2013
  9. Junio C HamanoDec 2, 2013
  10. Christian CouderDec 3, 2013
  11. Christian CouderDec 3, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.