"Phillip Wood via GitGitGadget" [off-list ref] 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?
In the meantime, I'll queue the patch as-is (I actually queued the
previous round with namefix already).
Thanks.
On 07/10/2021 22:23, Junio C Hamano wrote:
"Phillip Wood via GitGitGadget" [off-list ref] writes:
quoted
* 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 ...
quoted
- 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.
In the meantime, I'll queue the patch as-is (I actually queued the
previous round with namefix already).
Thanks
Phillip
Thanks.
On 10/8/2021 5:09 AM, Phillip Wood wrote:
On 07/10/2021 22:23, Junio C Hamano wrote:
quoted
"Phillip Wood via GitGitGadget" [off-list ref] writes:
quoted
* 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 ...
quoted
- 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.
That particular patch is old and is due to some interactions with
how VFS for Git (ab)uses the skip-worktree bit. I'm not sure it will
ever come upstream. It is probably very much like a recent example [1]
that we tried to upstream only to realize that it should be replaced
with something better.
[1] https://lore.kernel.org/git/65905bf4e001118e8b9ced95c1bcecbacb6334ac.1633013461.git.gitgitgadget@gmail.com/
I'm fine to leave the `-q` out of this patch and I can add it myself
when we take this into microsoft/git. That can also motivate me to
rethink that patch.
Thanks,
-Stolee