When migrating a project from one heavily-used library X to another library Y which is essentially equivalent but doesn't have the same API, it may be necessary to make a lot of changes. In the case I'm working on right now, ≈500 additions and deletions: not impossible, but I'd normally say, that's too many for a single commit! (I have in the past had quite some negative experience with too-big commits, and the arising merge conflicts.)
But with only a subset of the changes done, the project doesn't compile. Furthermore, the changes are essentially mechanical: for every function
foo previously used from X, there's either a
foo' in Y that does exactly the same thing (despite having a different name) or only a very simple wrapper needs to be written.
Is it sensible to first make all the changes and put them in a single commit, or should I better try to split it up somehow? How is this handled when multiple people are working on the refactoring and you can't really wait till it's all done before interacting via VCS – “single-use commits” that are squashed before merging into the master branch, or something else?