src/content/: Update all files left to asciidoc

1 files changed, 34 insertions, 43 deletions

diff --git a/src/content/tils/2020/09/05/oldschool-pr.adoc b/src/content/tils/2020/09/05/oldschool-pr.adoc
index 5b4e445..c1c56b7 100644
--- a/src/content/tils/2020/09/05/oldschool-pr.adoc
+++ b/src/content/tils/2020/09/05/oldschool-pr.adoc
@@ -1,43 +1,32 @@
----
+= Pull requests with Git, the old school way
 
-title: Pull requests with Git, the old school way
+:empty:
+:cgit: https://git.zx2c4.com/cgit/
 
-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!
+create on a Git hosting provider’s web
+UI{empty}footnote:pr-webui[
+  And maybe even using the Git hosting provider’s API from the command line!
+] 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
+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
+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/
+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.
 
-## `git request-pull` introduction
+== `git request-pull` introduction
 
-Here's the raw output of a `git request-pull`:
+Here’s the raw output of a `git request-pull`:
 
-```shell
+[source,shell]
+----
 $ git request-pull HEAD public-origin
 The following changes since commit 302c9f2f035c0360acd4e13142428c100a10d43f:
 
@@ -57,35 +46,39 @@ EuAndreh (1):
 
  _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
+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
+`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
+[source,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
+== Delivering decentralized pull requests
+
+:cli-email: link:../04/cli-email-fun-profit.html
 
 Now that you can create the content of a pull request, you can just
-[deliver it][cli-email] to the interested parties email:
+{cli-email}[deliver it] to the interested parties email:
 
-```shell
+[source,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"
 
@@ -97,14 +90,14 @@ git request-pull -p HEAD~5 public-origin | \
 # 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
 
-## Conclusion
+:distgit: https://drewdevault.com/2018/07/23/Git-is-already-distributed.html
 
-In practice, I've never used or seen anyone use pull requests this way:
-everybody is just [sending patches via email][decentralized-git].
+In practice, I’ve never used or seen anyone use pull requests this way:
+everybody is just {distgit}[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
@@ -114,5 +107,3 @@ 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