Re: [gentoo-dev] On banning merge commits

[Rich Freeman]

On Sun, May 8, 2016 at 7:25 AM, Andreas K. Hüttel <dilfridge@g.o> 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