Not sure why I can't reply in a technical discussion. I have to edit to answer your question @danparsonson
> if I'm working on a long series of changes across multiple days, and halfway through it the code doesn't build yet?
That's why you break them down into small commits. The early you push it to CI, the earlier you will know whether each commit builds. For example, push commit 1 2 3 to the CI when they are ready. When the CI is running, you are working on commit 4 5 6
> The code won't pass CI because I'm not finished, but I want to commit my progress
If your commit 1,2,3 are ready, just ship them. It doesn't stop you have a few commits in reviews and a few WIP commits. There is no down time
Perhaps I misunderstand you but what if I'm working on a long series of changes across multiple days, and halfway through it the code doesn't build yet? The code won't pass CI because I'm not finished, but I want to commit my progress so I don't lose it if something goes wrong, and I can roll back if make mistakes.
To us the mental model is minimum. All you need to do is to make sure each commit pass CI. You can ship any number of stacked commits together
----------------------------------------------------------------------------------------------------
Not sure why I can't reply in a technical discussion. I have to edit to answer your question @danparsonson
> if I'm working on a long series of changes across multiple days, and halfway through it the code doesn't build yet?
That's why you break them down into small commits. The early you push it to CI, the earlier you will know whether each commit builds. For example, push commit 1 2 3 to the CI when they are ready. When the CI is running, you are working on commit 4 5 6
> The code won't pass CI because I'm not finished, but I want to commit my progress
If your commit 1,2,3 are ready, just ship them. It doesn't stop you have a few commits in reviews and a few WIP commits. There is no down time