3 ms·

Merge commits also break regression finding, since if you checkout a commit that was part of a merge, you land in a tree state reflecting what tree at this com

Merge commits also break regression finding, since if you checkout a commit that was part of a merge, you land in a tree state reflecting what tree at this commit looked like before the merge, which is a state the master branch has never been in. It often breaks things which work both before and after the merge commit. So you can never find with certainty the regression point at commit level, other than locally linearising this merge into a series of cherry picks. It’s just awful.

dbt00 3y ago
--first-parent, and both with git bisect and many other things, is your friend here.
- yakubin 3y ago
  That doesn’t fix the issue I described. It leads to a situation where you can say that a merge introduced a regression, but you don’t know which of the merged commits did, because it skips over them all. So it’s not commit-level.
leghifla 3y ago
On the other hand, rebasing can create its own problems re: regression finding If you rebase more than one commit, you can also have an intermediate commit which does not run fine, or even compile. This can happen silently, without conflict resolution while you rebase. Think a function call in trunk needs one additional parameter. So you have a commit message saying "Protocol X tested successfully with Y", which was true when the code done and tested. After the rebase, it might not run anymore because of changes done in the trunk. You will probably notice it and correct it in a later commit, but good luck in 3 month when someone points a bug at protocol X and you want to re-run the test in this commit...
- yakubin 3y ago
  That’s why at work we have a “commit queue” that tests that every commit builds as it comes in in the order it’s merged (or more accurately: cherry-picked). Don’t leave those things to manual checks and human vigilance. They’re too fallible.
- the_gipsy 3y ago
  I think this can be mostly worked-around by requiring branches (PRs) to be rebased and tested/CI-passed before merging. If PRs contain multiple commits, either squash them (on merge or before), or use some kind of queued / stacked PR system.

dbt00 3y ago

--first-parent, and both with git bisect and many other things, is your friend here.

yakubin 3y ago
That doesn’t fix the issue I described. It leads to a situation where you can say that a merge introduced a regression, but you don’t know which of the merged commits did, because it skips over them all. So it’s not commit-level.

leghifla 3y ago

On the other hand, rebasing can create its own problems re: regression finding If you rebase more than one commit, you can also have an intermediate commit which does not run fine, or even compile. This can happen silently, without conflict resolution while you rebase. Think a function call in trunk needs one additional parameter. So you have a commit message saying "Protocol X tested successfully with Y", which was true when the code done and tested. After the rebase, it might not run anymore because of changes done in the trunk. You will probably notice it and correct it in a later commit, but good luck in 3 month when someone points a bug at protocol X and you want to re-run the test in this commit...

yakubin 3y ago
That’s why at work we have a “commit queue” that tests that every commit builds as it comes in in the order it’s merged (or more accurately: cherry-picked). Don’t leave those things to manual checks and human vigilance. They’re too fallible.
the_gipsy 3y ago
I think this can be mostly worked-around by requiring branches (PRs) to be rebased and tested/CI-passed before merging. If PRs contain multiple commits, either squash them (on merge or before), or use some kind of queued / stacked PR system.