[dmd-internals] Automatic Pull Merging!

[Leandro Lucarella]

Brad Roberts, el 15 de November a las 09:45 me escribiste:
> 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.

I don't understand this, honestly. Anyone with push rights can alter
commits, just amend and push. You can create a new commit impersonating
other people, just use their name and e-mail as the author.

> 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).

But I understand this point.

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

Yeah, that would be the ideal, but I'm not very hopeful about this...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si ella es el sol, yo soy la luna
Si ella es el mar, soy el desierto
Y estamos en eclipse total
Y estamos en eclipse total