On Sun, May 8, 2016 at 7:25 AM, Andreas K. Hüttel <dilfri...@gentoo.org> wrote: > > * However... as the past months have shown, when using merges it is much > easier to accidentally mess up the entire tree than using rebases alone. >
How does a merge make it any easier/harder to mess up the entire tree? I can see how they can make the history easier/harder to read but in the end I believe the content of the tree itself ends up being whatever was in the index when you made the commit. > > * The only alternative would be to come up with criteria for merges and > actually enforce them (meaning, if you mess up the tree more than twice you > lose your push access. Hello QA.). > Here is the other only alternative: use rebase commits when they're most appropriate, and use merge commits when they're most appropriate, and publish easy-to-understand guidelines for when each is the case. I don't really see a need for hard rules unless we think devs can actually comply with them. Do we really want somebody to lose their commit access because they pushed a string of rebased commits that might have been more appropriate as a single merge commit? Both types of commits have their place. I think that bans are better used for bad attitude than for mistakes. I don't think you need a 100% rigid rule to enforce a ban either - this isn't a court of law (and I think many of the failings of courts of law result from the rigid application of rules, but that is a different matter). -- Rich
