Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > On 07/10/2021 22:23, Junio C Hamano wrote: >> "Phillip Wood via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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@xxxxxxxxx/ >> 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.
