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 _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
