On 9 May 2016 at 00:09, Anthony G. Basile <bluen...@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
