[hinkley]

> We have even had a customer recently complain about a bug, which we fixed in a few hours, but the next week they had to complain about the bug again because it was back.

An interaction like this was the genesis of me spending a lot more time trying to understand code via the commit history instead of just looking at what's in front of me. That in turn made me highly opinionated about bad commit hygiene practices.

There's a class of regressions that is caused by interaction between two features. As long as one exists, the other does not work. Until someone sits down with a three way merge of sorts, and finds a new solution that allows both features to work at the same time, you're just going to ping-pong between two open bug reports. The only way I know to get past this is to figure out what both developers were trying to do, for which the commit history is often the cheapest option.

So we do things like require bug numbers in commit messages, pester people to learn to do move operations the 'right way', push back on squash operations, separate formatting changes from functional changes, use revert operations to remove bad code, and so forth. Like any safety procedure, they seem like a waste of time and energy until something bad happens.

[jrochkind1]

> you're just going to ping-pong between two open bug reports.

I guess you don't have an automated test suite that would prevent you from committing code that causes a previously fixed bug to come back? (Ie, the real meaning of "regression")