3 ms·

I'm with you (see my other top level comment), but > Then you're simply a `git revert` away from undoing it, without risking breaking anything else This needs

I'm with you (see my other top level comment), but > Then you're simply a `git revert` away from undoing it, without risking breaking anything else This needs careful qualification. On GitHub at least, it is difficult to ensure every commit passes CI. This can result in skipping during bisect for a busted commit. It doesn't happen often enough in my experience too convince me to give up a cleaner history, but it's a downside we should acknowledge. Ideally GitHub would make testing each individual commit easier.

keybored 2y ago
A revert two weeks after the fact will create a new and unique tree (untested) in any case. I don’t if you’re saying that the original commit or the revert might be untested. In either case the brand new revert could break something. Who knows, it’s a new state. > It doesn't happen often enough in my experience too convince me to give up a cleaner history, but it's a downside we should acknowledge. There are tools for that. https://github.com/mhagger/git-test https://github.com/mhagger/git-test
- burntsushi 2y ago
  All I'm trying to do is qualify things so that the trade offs can be more honestly assessed. The bisect for finding that commit might not work as well as you hope if you need to skip over commits that don't build or whose tests fail for other reasons. Those things can happen when you aren't testing each individual commit. I understand there are tools for testing each individual commit. You'll notice that I didn't say it's impossible to ensure every commit is tested. Needing to use random tools to do it is exactly what makes it difficult. And the tool you linked says literally nothing about using it in CI. How good is its CI integration? There's more to it than just running it. On top of all of that, there are more fundamental problems, like increasing CI times/costs dramatically for PRs split into multiple fine grained commits. Again, anyone here can go look at my projects on GitHub. I try hard to follow atomic commits. I think it's worth doing, even with the downsides. But we shouldn't try to make things look rosier than they actually are.

keybored 2y ago

A revert two weeks after the fact will create a new and unique tree (untested) in any case. I don’t if you’re saying that the original commit or the revert might be untested. In either case the brand new revert could break something. Who knows, it’s a new state. > It doesn't happen often enough in my experience too convince me to give up a cleaner history, but it's a downside we should acknowledge. There are tools for that. https://github.com/mhagger/git-test https://github.com/mhagger/git-test

burntsushi 2y ago
All I'm trying to do is qualify things so that the trade offs can be more honestly assessed. The bisect for finding that commit might not work as well as you hope if you need to skip over commits that don't build or whose tests fail for other reasons. Those things can happen when you aren't testing each individual commit. I understand there are tools for testing each individual commit. You'll notice that I didn't say it's impossible to ensure every commit is tested. Needing to use random tools to do it is exactly what makes it difficult. And the tool you linked says literally nothing about using it in CI. How good is its CI integration? There's more to it than just running it. On top of all of that, there are more fundamental problems, like increasing CI times/costs dramatically for PRs split into multiple fine grained commits. Again, anyone here can go look at my projects on GitHub. I try hard to follow atomic commits. I think it's worth doing, even with the downsides. But we shouldn't try to make things look rosier than they actually are.