Should the code change and corresponding change in the test suite be performed in one commit or split into two? Consider the case of error correction, which causes a slight change in the expected result, which leads to minor changes in the test suite. It is very convenient to have both changes in the same commit, as this makes it obvious to the reviewer what has changed as a result. On the other hand, sometimes you just need to look at diff for the source or the difference with the expected output, and it is much easier to do if the commits are separate. In addition, the two things are logically different, so it makes sense to make clear commits.
I would like to make two different commits, but somehow they have two connections that are related to each other (so that I can select, return, etc. both are fixed as an atomic unit). In addition, if two excellent commits are made, then the test suite will fail on the first commit (unless a third commit is introduced to weaken the test suite), which will lead to pain in the future. The problem with future bisects, which does not work at all, generally encourages me to make one commit, but the commits should be logically different units, and the commit code is logically different from the commit to the expected result in the test suite.
Is there a way to make two excellent fixations and not bend backwards to prevent bisection on one of them? (e.g. to explicitly specify commits to skip)
source share