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