Re: [gentoo-dev] On banning merge commits

[Anthony G. Basile]

On 5/8/16 8:34 AM, Rich Freeman wrote:
> On Sun, May 8, 2016 at 8:18 AM, Kent Fredric <kentfredric@×××××.com> wrote:
>> On 9 May 2016 at 00:09, Anthony G. Basile <blueness@g.o> 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
>>
>> 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.
>>
>
> ++
>
> merges shouldn't just be used for random pull-requests.  However, when
> you're touching multiple packages/etc they should be considered.

i was actually thinking of sec-policy where i remember writing a script
back in the CVS days that did some 200 commits, one after another.  i
was migrating some work for Swift from an overlay to the main tree.


They
> should also be considered if for some reason you had a bazillion
> commits to a single package that for some reason shouldn't be rebased.

a bazillion commits to a category that almost no one touches and except
one person or team, like sec-policy or dev-perl etc.

so again, i'm against an outright banning of merge commits, but we need
to restrict them to reasonable cases, "reasonable" being judged by the
community.

> I imagine that they'll be a small portion of commits as a result.
> However, for the situations where they're appropriate they make a lot
> of sense.
>
> This was some of Duncan's point, but I will comment that we'll never
> have as clean a history as the kernel simply because we don't have a
> release-based workflow with the work cascading up various trees.  The
> kernel is almost an ideal case for a merge-based workflow.  I imagine
> that half of Gentoo's commit volume is random revbumps and keyword
> changes and that is just going to be noise no matter what.  If we were
> release-based we could do that stuff in its own branch and merge it
> all in at once, but that just isn't us.
>
> --
> Rich
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA