Re: [gentoo-dev] On banning merge commits

[Kent Fredric <kentfredric@gmail.com>]

On 9 May 2016 at 00:09, Anthony G. Basile <blueness@gentoo.org> wrote:
> 1. announce to gentoo-dev@ the intention to start a branch intending to
> merge
>
> 2. hack hack hack
>
> 3. test the merge for any conflicts etc,
>
> 4. announce to the list a date/time to merge
>
> 5. if okay, ermge


I think that's a bit excessive myself. I dislike merges, but I don't
hate them *quite* that much to justify such formality.

Because IMO, its not about forbidding merges, its about making sure
the use of merges is appropriate and effective.

For instance, stabilizing ~100 ebuilds in response to a single stable
request, it would make logical sense to group all those stabilizations
so that they appear on the left side as a single atomic change, while
still existing as a series on the right side of the branch for
historical accuracy
and for other practical reasons ( like simplified commit reverts )

Pretty much *anything* that does "bulk changes for single purpose" is
a good candidate for a merge.

For instance, there's ~100 commits sitting around somewhere in a
repository for introducing Perl 5.24 to the tree, which requires a
commit for each and every entry in virtual/perl-*

It would make much sense for this series to be visible on Master as a
"add Perl 5.24 to tree" commit, because all the changes are inherently
interdependent,
and it would make little sense to rewind to a specific point within
that series and use it as a portage tree.

But that's not significant enough to warrant a lot of formal fluffing around.

It for sure would be best if that 100 commit range was rebased before
merging, but it should still be a non-fast-forward merge just to keep
the history logical.



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL