On Tue, Jul 14, 2015 at 05:06:31PM +0100, Ian Jackson wrote:
> 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.
>
> Right.
>
> > 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.Yes, `git pull-request` was a thought experiment, an imaginary tool. But if there is server side support for anyone to push to some ref in the maintainer's repository without any authentication in a way that won't otherwise interefere with the maintainer's regular trees, the client side "should be easy". > > 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 ? yes. maybe it could also be done client side, I don't know. > > 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. I guess the point is storing all of if it the repository itself, -- Antonio Terceiro <terce...@debian.org>
signature.asc
Description: Digital signature
