On Wednesday, July 3, 2024 3:18 PM, Derrick Stolee wrote: >On 7/3/24 2:16 PM, Junio C Hamano wrote: >> "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: >> >>> From: Derrick Stolee <stolee@xxxxxxxxx> >>> >>> 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
