Difference between 'git request-pull' and 'pull request'

Question

What is git request-pull and how does it compare to making a pull request, e.g. on github?

1. How is it supposed to be used?

2. Can it be used as replacement for pull requests (e.g. on github)?

3. What are the advantages of using it?

Answer 1

The git request-pull command predates hosting services. As noted in comments, it's meant for a workflow that tends to include running git format-patch and git send-email to pass patches around via email. Once the patches have been tested and approved, the patch-generator might make the commits accessible on a public server that they or their company provide, and send a final email message to the project maintainer announcing that they have the cleaned-up, rebased, etc., project-topic ready for merging.

For example, suppose a guy named Phil Systeme has a Linux kernel patch for a file system. He has a clone of the Linux kernel tree, as of some Linux release. His patch consists of one giant commit to a dozen or so files, which he sends to the file-system maintenance list, with a subject line:

PATCH: make the foo file system better

The feedback on the file-system maintenance mailing list first says: break this into at least six smaller parts. Phil Systeme breaks up his Phile System patch into eight logical smaller patches, each of which does something useful and still builds. He sends out 9 messages this time:

[PATCH v2 0/8]: make the foo file system better

(description of what the patch series is about)

[PATCH v2 1/8]: split up the xyzzy function

As a prerequisite for improving the foo file system, break
a large function into several smaller ones that each do one
thing.  We'll use this later to work better and add new features.

[PATCH v2 2/8]: ...

This time, he gets feedback that says it looks better but he forgot to account for the fact that ARM cpus require one special thing and MIPS CPUs require a different special thing. So he sends out a third round of [PATCH v3 m/n] messages, and so on.

Eventually, the file system maintenance lieutenant(s) agree that this patch should go in. Now Phil, or the lieutenant, converts the emailed patches to actual Git commits, applied to a current development kernel, or to a maintenance kernel, or whatever. Linus Torvalds trusts this person enough at this point that this person can say: "here is a Git repository with new commits that you should add to the kernel." Linus can then git pull directly from this other repository, or more likely, git fetch from there and decide whether and how to merge them, or whether to insult the person. :-)

---

Hosting services like GitHub and Bitbucket claim, or feel, or whatever verb you like here, that their "pull request" mechanism is superior to all this email. In some ways, it pretty clearly is; but their enthusiasm for hiding the actual commit graph, which really does matter if you're going to use a true merge, is kind of a mystery to me.