On Sat, Jul 11, 2015 at 06:12:26PM +0100, Ian Jackson wrote:
> Ben Finney writes ("Re: GitHub “pull request” is proprietary, incompatible
> with Git ‘request-pull ’"):
> > My reading of <URL:https://developer.github.com/v3/#authentication>
> > leads me to infer there's no way for to submit a GitHub “pull request”
> > without having a GitHub account.
> >
> > Decentralisation would require that anyone with a Git repository can
> > submit a GitHub “pull request” without any need for a GitHub account.
> > I'd love to learn if that's possible now.
>
> This subthread is in danger of going off into the weeds.
>
> For the avoidance of any doubt: I was volunteering to do some work if
> we can figure out what the work is that needse to be done (and it
> seems plausible to me, obviously).
>
> I am (obviously) not volunteering to fix Github itself. That is not
> possible for me, only for Github.
>
> The way I am offering to help is this: there seems to (or some people
> are saying there is) a lack of straightforward server-side software
> which (i) project maintainers can run on a suitable friendly server
> and (ii) contributors who are used to a github workflow can interact
> with reasonably easily.
>
> If someone (preferably several people) who want such a thing would
> like to (get together and) write a simple specification for what they
> want (and how it differs from or plugs into gerrit, gitorious etc.), I
> am still offering to write it.
>
> I don't have a need for such a thing myself right now, but I have the
> server side implementation experience. Provided the requirements
> don't include too many awkward bells and whistles, I think it ought to
> be not too big a job.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 ----------------------------------------------------------------------- 1) obtain repository (git clone) 2) branch off master (or any other branch) to a branch named, say, `bugfix`. 3) hack and produce one or more commits in the `bugfix` branch. 4) be able to submit that branch as a pull request to the master branch on the original repository. I would imagine a UI like this: $ git pull-request submit $ORIGBRANCH $PATCHSET (in this example $ORIGBRANCH would be `master`, and $PATCHSET would be `bugfix`) 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. I would imagine that this process would make sure that the top of HEAD is a fast forward on top of the target remote branch, an maybe rebase the submitted branch before submitting. on the maitainer side ----------------------------------------------------------------------- 1) git fetch/pull merge requests are available locally at a given namespace, say, refs/merge-requests/$id, where $id could be e.g. a autoincremented number, what shouldn't be hard since pushes already lock the target repository anyway. 2) git pull-request test $id switches to a local branch which has the latest commit on pull request 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. 3.2) git pull-request reject $id The maintainer would type a message saying why that pull request is being rejected, and the pull request would somehow be marked as such. When the maintainer pushes, the submitter should be notified that the pull request has been rejected, with the reason why. 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. when the maintainer pushes, the submitter should be notified of the review. It would be nice to somehow support re-submitting a reviewed pull request, and to be able to recognize a second pull request as a new version of a previous one. What gerrit does is assigning a unique Id to each commit at submission time, and stores it at the commit message as something like `Commit-Id: 12037123721983792187398217`, so if you rebase/ammend, it can still associate the new commit with the old one as long as you keep the identifier in the commit message. When you resubmit it knows that that new commit is a new version of the first one. I have mostly no idea on how this could be implemented, and I'm also not sure that these imaginary UI would be the best one, but I hope that these ideas are useful to start a conversation. -- Antonio Terceiro <terce...@debian.org>
signature.asc
Description: Digital signature
