Dun Peal <dunpealer@xxxxxxxxx> writes: > All of our branches right now are feature branches of master, whose > short lives end with a single merge back. Thus, merging back as a > single patch implementing that single feature is ideal: the branch was > only created to implement the feature, so by definition all of its > individual commits are intermediary, and once the final feature state > is achieved, the incremental steps leading to it are not interesting > at all - they're just noise! You sounds as if none of your developers make mistakes and your reviewers are always so perfect that you have absolute confidence that all the possible bugs are killed in these feature branches before they are merged to the master. That does not sound like a real world to me, though. When a fix or tweak is needed for codepaths introduced by these feature branches after they are merged to master, the cleanest thing to do is to queue the fix on top of the branch that needs that fix or tweak, and merge that to master. Of course, you can choose to abandon these feature branches that are potentially buggy and fork a fix branch from the master branch that was current when the bug happened to be discovered. But that would make the backporting bugfixes (or feature tweaks for that matter) to anything older a lot harder. > Why would John care that while implementing feature X, Jill committed > her half-state Y so she can go home, or made and fixed typo Z ? In > fact, why would Jill care a day, let a lone a couple of months, after > X was completed and merged to master? Who is merging half-state to 'master' or merging 'master' back to the feature branches? I don't think any of the above relates to the topic of 'merge --squash' anyway... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html