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

RE: [PATCH] advice: warn when sparse index expands

From
rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date
Jul 3, 2024, 19:28 UTC
Message-ID
<084501dacd7f$38ac7d60$aa057820$@nexbridge.com>
In-Reply-To
<068752a3-4140-4b30-803a-1c409afb01e1@gmail.com>
On Wednesday, July 3, 2024 3:18 PM, Derrick Stolee wrote:
Show 36 quoted lines
>On 7/3/24 2:16 PM, Junio C Hamano wrote:
>> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>
>>> From: Derrick Stolee <stolee@gmail.com>
>>>
>>> Typically, forcing a sparse index to expand to a full index means
>>> that Git could not determine the status of a file outside of the
>>> sparse-checkout and needed to expand sparse trees into the full list
>>> of sparse blobs. This operation can be very slow when the
>>> sparse-checkout is much smaller than the full tree at HEAD.
>>>
>>> When users are in this state, it is common that 'git status' will
>>> report the problem. Usually there is a modified or untracked file
>>> outside of the sparse-checkout mentioned by the 'git status' output.
>>> There are a number of reasons why this is insufficient:
>>
>> Nicely written to explain why giving an advice message is a good idea
>> to cover this situation.
>>
>> Making it possible to squelch comes with no cost (once the code to do
>> so is written), so I do not have a huge problem with the use of
>> advise_if_enabled(), but I offhand do not know if the users would ever
>> want to squelch it.  Is this something that users would choose to say
>> "yes, I know what I am doing is making my sparse working tree
>> unusuably slow and I've heard how to whip my sparse working tree into
>> a better shape already---please do not tell it to me ever again;
>> because I need to leave these crufts outside the sparse cone anyway, I
>> am willing to accept the unusually slow response, overhead, and wasted
>> cycles and power" to?
>
>I currently can't imagine a case where a user would want to disable this advice, but I
>defaulted to allowing it. I suppose it is more difficult to remove that option later, so I
>should have defaulted to not having it removable via config.
>
>I can send a v2 without the config option present. (I'll wait a day or two to see if
>others have strong opinions.)

One possible use case is during a CI test of user code where they need to do something that causes the advice, but don't want to see the message in their logs. --Randall

Previous: Derrick StoleeNext: Junio C Hamano
Message 4 of 10 in “advice: warn when sparse index expands”
  1. advice: warn when sparse index expandsDerrick Stolee via GitGitGadget, Jul 3, 2024
  2. Junio C HamanoJul 3, 2024
  3. Derrick StoleeJul 3, 2024
  4. rsbecker@nexbridge.comJul 3, 2024
  5. Junio C HamanoJul 3, 2024
  6. Rubén JustoJul 3, 2024
  7. Elijah NewrenJul 5, 2024
  8. Derrick StoleeJul 8, 2024
  9. advice: warn when sparse index expandsDerrick Stolee via GitGitGadget, Jul 8, 2024
  10. Junio C HamanoJul 8, 2024

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.