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

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

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,

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

  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

  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

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

Reply to: