[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GitHub “pull request ” is proprietary, incompatible with Git ‘requ est-pull ’

Antonio Terceiro writes ("Re: GitHub “pull request ” is proprietary, incompatible with Git ‘requ est-pull ’"):
> I have a few ideas about this. I have used gerrit before, and it
> provides a really nice experience except for 2 little facts:
> - you have to use a web UI thingy to review patches (although that said
>   web UI does have a really nice keyboard-based navigation support)
> - the server side is quite heavyweight, so both running your own and
>   packaging it for Debian seems to be difficult.


> I would be very happy if something that works more or less like gerrit
> but without the above issue existed. I would imagine something along
> these lines:
> on the submitter side
>   $ git pull-request submit $ORIGBRANCH $PATCHSET

This syntax requires that the user have some special
`git-pull-request' tool.  An alternative would be:

    $ git push git://some/url HEAD:$ORIGBRANCH

And the server side would do this:

>   This would create a specially named ref on the maintainer's
>   repository, and the maintainer should be notified somehow that such a
>   pull request exists. Notifications methods could be plugged, so that
>   you can choose to enable notification by email, IRC, or what have you.
>   Of course notifications by email is the obvious choice, given commits
>   come with email addresses.
> on the maitainer side
> -----------------------------------------------------------------------
> 3.1) git pull-request accept $id
>   I imagine this could be as easy as a simple wrapper around `git
>   merge`. when the maintainer pushes the branch, it would be really
>   awesome if the server noticed which pull requests have been merged,
>   and notify the submitters of that.

Notify by email, you mean ?

> 3.3) git pull-request review $id
>   This would probably be the hardest part, since we would need to devise
>   a reasonable UI for the maintainer to comment on the contents of the
>   patches. I would imagine that being able to record some review message
>   against each hunk of the diffs would be a good beginning. Being able
>   to add line-by-line comments, as gerrit allows, would be awesome.

I think this is probably future work.

One approach would be

  git review-push patchbomb-myself $id

which would use git-format-patch and git-send-email in some fairly
automatic way.  Then you could reply to the individual patch messages
by email.


Reply to: