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 UI1 like
GitLab/Bitbucket/GitHub actually comes from Git itself:
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 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://git.euandreh.xyz/website/ 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
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: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 email@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 HEAD~5 public-origin -p | \ mail firstname.lastname@example.org -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 email@example.com -s 'PR: All commits from my "other-brach"'
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.
git help request-pull for more info.
And maybe even using the Git hosting provider’s API from the command line! ↩