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 <terceiro@debian.org>
Attachment:
signature.asc
Description: Digital signature