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
|
#
msgid ""
msgstr ""
msgid ""
"title: Pull requests with Git, the old school way\n"
"date: 2020-09-05\n"
"layout: post\n"
"lang: en\n"
"ref: pull-requests-with-git-the-old-school-way"
msgstr ""
msgid ""
"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`."
msgstr ""
msgid ""
"[^pr-webui]: And maybe even using the Git hosting provider's API from the "
"command line!"
msgstr ""
msgid ""
"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?\"."
msgstr ""
msgid ""
"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](https://git.zx2c4.com/cgit/about/) installation. No need to be locked"
" in by any of them, putting the \"D\" back in \"DVCS\": it's a "
"**distributed** version control system."
msgstr ""
msgid "`git request-pull` introduction"
msgstr ""
msgid "Here's the raw output of a `git request-pull`:"
msgstr ""
msgid ""
"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`\"."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"A simple solution for that is for you to add the `public-origin` alias as "
"the HTTPS alternative to the SSH version:"
msgstr ""
msgid "Every Git hosting provider exposes repositories via HTTPS."
msgstr ""
msgid "Experiment it yourself, and get acquainted with the CLI."
msgstr ""
msgid "Delivering decentralized pull requests"
msgstr ""
msgid ""
"Now that you can create the content of a pull request, you can just [deliver"
" it][cli-email] to the interested parties email:"
msgstr ""
msgid ""
"[cli-email]: {% link _tils/2020-09-04-send-emails-using-the-command-line-"
"for-fun-and-profit.md %}"
msgstr ""
msgid "Conclusion"
msgstr ""
msgid ""
"In practice, I've never used or seen anyone use pull requests this way: "
"everybody is just [sending patches via "
"email](https://drewdevault.com/2018/07/23/Git-is-already-distributed.html)."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"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."
msgstr ""
msgid "Check `git help request-pull` for more info."
msgstr ""
|
