Pull requests with Git, the old school way

It might be news to you, as it was to me, that “pull requests” that you can create on a Git hosting provider’s web UI¹ like GitLab/Bitbucket/GitHub actually comes from Git itself: git request-pull.

At the very core, they accomplish the same thing: both the original and the web UI ones are ways for you to request the project maintainers to pull in your changes from your fork. It’s like saying: “hi there, I did some changes on my clone of the repository, what do you think about bringing those in?”.

The only difference is that you’re working with only Git itself, so you’re not tied to any Git hosting provider: you can send pull requests across them transparently! You could even use your own cgit installation. No need to be locked in by any of them, putting the “D” back in “DVCS”: it’s a distributed version control system.

git request-pull introduction

Here’s the raw output of a git request-pull:

$ git request-pull HEAD public-origin
The following changes since commit 302c9f2f035c0360acd4e13142428c100a10d43f:

  db post: Add link to email exchange (2020-09-03 21:23:55 -0300)

are available in the Git repository at:

  https://euandre.org/git/euandre.org/

for you to fetch changes up to 524c646cdac4153e54f2163e280176adbc4873fa:

  db post: better pinpoint sqlite unsuitability (2020-09-03 22:08:56 -0300)

----------------------------------------------------------------
EuAndreh (1):
      db post: better pinpoint sqlite unsuitability

 _posts/2020-08-31-the-database-i-wish-i-had.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

That very first line is saying: “create me a pull request with only a single commit, defined by HEAD, and use the URL defined by public-origin”.

Here’s a pitfall: you may try using your origin remote at first where I put public-origin, but that is many times pointing to something like git@example.com, or git.example.com:repo.git (check that with git remote -v | grep origin). On both cases those are addresses available for interaction via SSH, and it would be better if your pull requests used an address ready for public consumption.

A simple solution for that is for you to add the public-origin alias as the HTTPS alternative to the SSH version:

$ git remote add public-origin https://example.com/user/repo

Every Git hosting provider exposes repositories via HTTPS.

Experiment it yourself, and get acquainted with the CLI.

Delivering decentralized pull requests

Now that you can create the content of a pull request, you can just deliver it to the interested parties email:

# send a PR with your last commit to the author's email
git request-pull HEAD public-origin | mail author@example.com -s "PR: Add thing to repo"

# send a PR with your last 5 commits to the project's mailing
# list, including the patch
git request-pull -p HEAD~5 public-origin | \
  mail list@example.com -s "PR: Add another thing to repo"

# send every commit that is new in "other-branch"
git request-pull master public-origin other-branch | \
  mail list@example.com -s 'PR: All commits from my "other-brach"'

Conclusion

In practice, I’ve never used or seen anyone use pull requests this way: everybody is just sending patches via email.

If you stop to think about this model, the problem of “Git hosting providers becoming too centralized” is a non-issue, and “Git federation” proposals are a less attractive as they may sound initially.

Using Git this way is not scary or so weird as the first impression may suggest. It is actually how Git was designed to be used.

Check git help request-pull for more info.