But I really don't like the trend of some folks "need a clean history" and then disabled merge commits.
It's like they are saying "cool snap shot system you got there, id hate for it to be use to take a bunch of incremental snap shots with specific notes attached to each one. Why don't you let me bundle those all together real purdy like and no one has to know it took you 20 commits to fix that decade old bug."
I have literally never heard a reasonable claim that needing a "clean main branch" is more useful in a retro or bisect.
Maybe other folks know of a concrete example?
It’s more like saying “in any writing process, revising is going to lead to better finished output.” It is absolutely true that no one needs to know that it took you 20 commits to fix that bug. It’s much easier to review 3 commits, one of which contains the refactoring done as part of the fix with the other two each containing changes that address distinct pieces of the bug. The structure of the change is clearer, and the structure of the attached notes will be clearer as well.
- Because you want to restructure the project for the whole history, prior to merging several projects.
[deleted]