[dmd-internals] Automatic Pull Merging!

[Brad Roberts]

On 11/15/13 6:17 AM, Leandro Lucarella wrote:
> Brad Roberts, el 15 de November a las 00:17 me escribiste:
>> I've just put the automated pull merging code into production and
>> visible to everyone.  The rough details:
>>
>> 1) You have to be logged in and using https (should be automatic) --
>> note the new login link in the upper left corner.  The website is
>> now integrated with github's oauth system and will direct you over
>> there to accept this login.  It requires write credentials because
>> the merge operation is performed as the person who requests the
>> merge.  This is subject to debate.  It's possible to switch to
>> read-only credentials and have all merges done as me, with a merge
>> comment noting who did the commit -- but I prefer it NOT be me but
>> rather be you guys.
>
> This is awersome!
>
> What do you think about rebasing instead? I always hated GitHub for
> using merge, and specially for using --no-ff option, it makes the
> history unreadable as a graph (duplicating basically each bugfix
> commit).

I too prefer rebase + ff merge.  However...

> The auth issues are the same though, except for the fact that if you
> don't rebase as the user that triggered the "merge", there is no way to
> say somebody else did it. But honestly, the "committer" information is
> so important to the point of completely screwing the repo history with
> tons of noise?

The auth issues are NOT the same.  I don't know that the git interface at github participates in the 
oauth impersonation mechanisms that the github api does.  If the oauth token is possible to use with 
github's git authentication it could be possible, but it expands the scope of what rights I acquire 
and use.  I'm not particularly comfortable with the concept of having sufficient rights to alter 
commits in any way.  The nefarious things that could be done are staggering.

Also, setting aside the auth issues, there's more going on behind the 'perform a merge' api than 
just the git interaction.  There's also all the hooks and events that are triggered.  I don't want 
to duplicate all the integration that github already does with bugzilla, closing the pull, updating 
the history of it, sending all the internal to github notifications, sending mails, etc (there's a 
ton of hooks, and though we only use a few, ignoring that integration is the wrong direction to head 
in).

IMHO, the right path here is lobbying for more control over the github merge process.