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