> If you look at a commit, there's no "anymore", no other timeframe rather that the commit's; it's either correct or incorrect on it's own. this is true but fr

> If you look at a commit, there's no "anymore", no other timeframe rather that the commit's; it's either correct or incorrect on it's own. this is true but frankly nothing i ever cared about. I think of commits as something that i can change and break and fix through rebasing, amending and the like. This mindset makes you a lot more flexible when handling commits, and when keeping in mind that the commit hashes change while doing that, I don't see any downsides. > It makes much more sense to merge each interface change from master to feature branch individually, resulting in atomic merge commits, each of which handles specific aspect, while staying correct. Then we have different views on what a horrible merge is. For me, that is having dozens of merge conflicts plus multiple necessary changes not indicated by conflicts, and most of those problems need to be resolved before the project compiles and the rest has to be resolved before all tests go green. There is no "while staying correct" in there. And this, working on lots of breakages at once, while needing to fix all of them before tests are green again, this i don't like at all and will be partly mitigated by the rebasing strategy. There certainly are advantages of merge commits, but in my (admittedly limited, especially when talking about larger projects) experience, resolving merge issues does get harder with them.