1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
---
title: Pull requests with Git, the old school way
date: 2020-09-05
layout: post
lang: en
ref: pull-requests-with-git-the-old-school-way
eu_categories: git
---
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[^pr-webui] like
GitLab/Bitbucket/GitHub actually comes from Git itself: `git request-pull`.
[^pr-webui]: And maybe even using the Git hosting provider's API from the
command line!
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][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.
[cgit]: https://git.zx2c4.com/cgit/
## `git request-pull` introduction
Here's the raw output of a `git request-pull`:
```shell
$ 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://euandreh.xyz/website.git/
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:
```shell
$ 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][cli-email] to the interested parties email:
```shell
# 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"'
```
[cli-email]: {% link _tils/2020-09-04-send-emails-using-the-command-line-for-fun-and-profit.md %}
## Conclusion
In practice, I've never used or seen anyone use pull requests this way:
everybody is just [sending patches via email][decentralized-git].
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.
[decentralized-git]: https://drewdevault.com/2018/07/23/Git-is-already-distributed.html
|
