Force pushed to revert some whitespace changes to the manifest my editor automatically weaseled in there. I'll propose normalizing TOML formatting separately.

It looks like PRs are configured to be squashed by default but rebase is an option. I suggest the split here is meaningful because in the event a later PR branched before this has a merge conflict or an API spelling problem comes up later, this split makes it easier to diagnose and re-correct (for the former scenario) or re-configure or upstream fixes (for the later scenario).

Sorry for the delayed response. I had a rest and didn't look into PRs in recent days. First, it is great to integrate more great tools into workflow, and typos should be great and well-known one, so I'll proceed with merge it. I shall need to learn how I can configure typos locally at the same time.

It looks like PRs are configured to be squashed by default but rebase is an option.

We can rebase, but squash isn't bad, because we also have git revert and git cherry pick to help edit sub commits a PR conveniently. A key advantage of rebasing in my eyes is that if we do rebase, everyone can view and each of the three commit messages at the top level of the commit history.

First, it is great to integrate more great tools into workflow, and typos should be great and well-known one, so I'll proceed with merge it. I shall need to learn how I can configure typos locally at the same time.

You shouldn't have to configure it at all, it will follow the project configs here. You don't even need it locally if you don't want. If you do, just run typos from the root of the project to see any potential errors it flags, and typos --write-changes if you want it to automatically fix them.

That's it.

We can rebase, but squash isn't bad, because we also have git revert and git cherry pick to help edit sub commits a PR conveniently.

This is not correct. If you squash, you do not have the ability to revert or cherry pick available any longer on the actual commits. Those tools only work at the commit level, and by definition if you squash the commits of a PR together you will no longer have them separately.

A key advantage of rebasing in my eyes is that if we do rebase, everyone can view and each of the three commit messages at the top level of the commit history.

Yes, and it will turn up the most related commit message in a future git blame, which might be useful in this case. I hope not, but renaming a bunch of symbols can have unexpected consequences if something happens to either use or be used publicly that I missed excluding. Having the automatic from the manually edited changes separately can be very useful in correcting things later if need be.

If you do, just run typos from the root of the project to see any potential errors it flags, and typos --write-changes if you want it to automatically fix them.

I remember my friend fixed some typos by typos using his local typos plugin, #177.

QuarticCat: My typos plugin keeps complaining so I fixed some.

This is what I would like to set up.

This is not correct. If you squash, you do not have the ability to revert or cherry pick available any longer on the actual commits.

To be clear, we can revert/cherry pick them as long as we have references stored in .git, and they'll not be garbage collected in local under some conditions. They might be even forever stored on GitHub's storage, but I'm not sure whether we can pull these references from GitHub explicitly. But you're correct, this is not safe.

I'm sure there are editor plugins and probably even LSP drivers for typos, but I don't happen to know exactly what is out there. Personally I just use the CLI tool and run it now and then.