On Sat, Jan 25, 2014 at 10:26:30AM -0800, Alfred Perlstein wrote: > On 1/25/14 9:51 AM, Baptiste Daroussin wrote: > > On Sat, Jan 25, 2014 at 12:57:21AM -0800, Alfred Perlstein wrote: > >> On 1/25/14, 12:11 AM, Yuri wrote: > >>> On 01/24/2014 20:16, Alfred Perlstein wrote: > >>>> (maybe there is some great ports system that I'm not aware of that > >>>> makes this all as easy github, but I somehow doubt that.) > >>> github itself is closed source, but 95% of its functionality is based > >>> on git which is open. One only needs to invoke 3-4 git operations to > >>> support what it does on the website side. Register on the site, fork > >>> the project under user's login, submit a pull request, merge a fork's > >>> branch to the main branch. All these are basically git commands. > >>> Without the glossiness of github, this is not that large of a project. > >>> Submitters will do the rest through git. > >>> > >>> I think, instead of tediously going through the PRs by hand, it is > >>> wiser to set up some system like this. > >>> > >> Agreed. +1000 > >> > >> Although if we go down the rabbit hole of building something "like > >> github" that might take a while. For now prototyping using the github > >> pull methods might be a good proof of concept. I may look into doing a > >> github pull request -> GNATS (src) PR gateway if time allows. > > Once again github pull request is the worst way of merging patches that > > exists. > > > > We already have problem with ugly and inaccurate logs, such pull request > > will > > make it even worse. > > > > Making proper merge from github pull request it not that easy, you will > > need to > > fetch pull request as custom branches and cherry-pick them. That is really > > not > > convenient. > Probably a dozen lines of shell. > Actually no: add this to your git config file
fetch = +refs/pull/*/head:refs/remotes/origin/pr/* Then all the pull request will be seen as branches you can safely cherry-pick. regards, Bapt
pgpanMjKzDlXA.pgp
Description: PGP signature
