Re: [PATCH v3] sparse index: fix use-after-free bug in cache_tree_verify()

> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> On 07/10/2021 22:23, Junio C Hamano wrote:
>>> "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>>
>>>>        * Fixed the spelling of Stolee's name (sorry Stolee)
>>>>        * Added "-q" to the test to prevent a failure on Microsoft's fork[1]
>>>>            [1]
>>>>       https://lore.kernel.org/git/ebbe8616-0863-812b-e112-103680f7298b@gmail.com/
>>> I've seen the exchange, but ...
>>>
>>>> -	for OPERATION in "merge -m merge" cherry-pick rebase
>>>> +	for OPERATION in "merge -m merge" cherry-pick "rebase --apply -q" "rebase --merge"
>>>>    	do
>>> ... it looks too strange that only one of them requires a "--quiet"
>>> option.  Is it a possibility to get whoever's fork corrected so that
>>> it behaves sensibly without requiring the "-q" option only for the
>>> particular rebase backend?
>>
>> The issue is caused by a patch that Microsoft is carrying that stops
>> apply from creating paths with the skip-worktree bit set. As they're
>> upstreaming their sparse index and checkout work I expect it will show
>> up on the list sooner or later. I agree the "-q" is odd and it also
>> means the test is weaker but I'm not sure what else we can do.
> 
> Perhaps passing "-q" to the other variant of "rebase" would make it
> clear that (1) we do not want to worry about traces involved in the
> verbose message generation and (2) there is nothing fishy going on
> in only one of the "rebase" backends.