Re: GitHub “pull request” is proprietary, incompatible with Git ‘request-pull ’
On 10 July 2015 at 15:38, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> I realise I'm coming to this conversation late, but:
>
> I have some experience of writing a stunt git push receiver. I would
> be willing to write another.
>
> The rough shape would be something like:
>
> * Instead of doing git-request-pull, submitter does git push to some
> special URL (perhaps an ssh git url, or perhaps a git:// one).
>
> * Software behind the url stores the incoming branch in an invented
> branch name in the master repo, so that `git fetch' can see it.
>
> * Invented branch name (or url or something) is shown to pushing
> user, as a reference.
>
> * Automatic email is sent to someone saying "someone pushed this for
> review" with branch name.
>
> AFAICT this is more or less like git-request-pull except that:
>
> - The objects are stored on the reviewers'/maintainers' system (so
> the submitter does not need to operate or use another git server)
>
> - The submitter interacts by doing `git push', not by sending an
> email.
>
> - The maintainers' can see the branches in git on their server.
>
What you have described here is github pull requests =) they use
refs/pull/# namespace though, so one needs to tweak fetch config to
get them all.
You similarly described gerrit here, one pushes to a magic
refs/for/master to create a merge proposal from here into
refs/for/master. However gerrit does something fance and splits each
commit into a separate merge proposal essentially which are all
stacked. (git review is just fancy wrappers around git push
HEAD:refs/for/something).
Above two do generate stand-alone emails.
Something more lightweight however would be hooks for gitolite. One
can already enable pushes that create branches there, and then further
restrict things. One would need a hook to generate email notifications
about new pushes. But there is a lightweight gating mechanism in place
already, e.g. by pushing refs to votes/$voter/$branch one can +1
things. https://github.com/sitaramc/gitolite/blob/master/src/VREF/VOTES
I have not looked into implementation details but I believe gitlab &
bitbucket expose merge proposals in a similar fashion.
The problem with all of these they are still centralised. gerrit is
slightly better, as it stores all the review details as git notes, and
thus one can migrate them away without any loss of information.
A distributed code review would be better, where one pushes and/or
uploads git bundle. (either to one's own, or to the public one for a
given project, or generic one) and then that is exposed as e.g.
shallow branches. Having a bridge for review comments as e.g. git
notes would be a win.
There is also a bridge between git send-email generated emails and
github pull requests. A project somewhere on github. By default it
generates branches, and send an email back to e.g. mailing list
"import as branch $foo, click here to create a pull request on github,
if you wish."
> (It may be that there is already some software that does this. If so
> I'm not aware of it.)
>
There are multiple, some of them are even free (gitlab, gerrit,
gitolite with hand written hooks) but all of them have it's own
semantics/workflows which may be sub-optimal.
> Tollef, would that be the kind of thing you would like to use ?
> If so I would be happy to discuss a more detailed specification with
> you and then implement it.
>
I want mentors.debian.net to accept git am formated patch / or a
debdiff against any packaging =) that would cover 90% of my review
needs in debian.
--
Regards,
Dimitri.
Reply to: