• Linux
• Linux-aarch64
• Windows

Basically I believe that each PR should have complete fix w/o build break for maintenance. this could be problem when we do cherry-pick.

@clalancette @Blast545 what do you think?

I think that would be good too, especially since I forgot to hit squash merge on the original PR 😅. But reverting would involve rewriting history which wouldn't be good

I think that would be good too, especially since I forgot to hit squash merge on the original PR sweat_smile. But reverting would involve rewriting history which wouldn't be good

Not quite. We can do a git revert, which doesn't rewrite history but makes a new commit that is the opposite of the original commit. Then we could do a new PR, including the original PR and this fix. That maintains history, and also keeps what @fujitatomoya is asking for.

I don't feel strongly about it either way, but I would strongly prefer that by end of day we either a) get the revert in, or b) get this fix in (I notice that it is failing all CI).

I don't have any preference as well, @fujitatomoya maybe just do what you think is best?

I passed in the wrong argument to CI, try these ones instead:

• Linux
• Linux-aarch64
• Windows

@fujitatomoya I've created a revert PR at #958 and I will submit a new PR with the new feature & all the fixes included