diff options
author | EuAndreh <eu@euandre.org> | 2024-11-18 08:21:58 -0300 |
---|---|---|
committer | EuAndreh <eu@euandre.org> | 2024-11-18 08:44:57 -0300 |
commit | 960e4410f76801356ebd42801c914b2910a302a7 (patch) | |
tree | 615d379416f72956d0c1666c63ce062859041fbe /src/content/tils/2020/09 | |
parent | Remove jekyll infrastructure setup (diff) | |
download | euandre.org-960e4410f76801356ebd42801c914b2910a302a7.tar.gz euandre.org-960e4410f76801356ebd42801c914b2910a302a7.tar.xz |
Diffstat (limited to 'src/content/tils/2020/09')
-rw-r--r-- | src/content/tils/2020/09/04/email-cli-fun-profit.adoc | 80 | ||||
-rw-r--r-- | src/content/tils/2020/09/05/oldschool-pr.adoc | 118 |
2 files changed, 198 insertions, 0 deletions
diff --git a/src/content/tils/2020/09/04/email-cli-fun-profit.adoc b/src/content/tils/2020/09/04/email-cli-fun-profit.adoc new file mode 100644 index 0000000..320f3ab --- /dev/null +++ b/src/content/tils/2020/09/04/email-cli-fun-profit.adoc @@ -0,0 +1,80 @@ +--- +title: Send emails using the command line for fun and profit! +date: 2020-09-04 +layout: post +lang: en +ref: send-emails-using-the-command-line-for-fun-and-profit +--- +Here are a few reasons why: + +1. send yourself and other people notification of cronjobs, scripts runs, CI + jobs, *etc.* + +2. leverage the POSIX pipe `|`, and pipe emails away! + +3. because you can. + +Reason 3 is the fun part, reasons 1 and 2 are the profit part. + +First [install and configure SSMTP][ssmtp] for using, say, Gmail as the email +server: + +```shell +# file /etc/ssmtp/ssmtp.conf +FromLineOverride=YES +MailHub=smtp.gmail.com:587 +UseSTARTTLS=YES +UseTLS=YES +rewriteDomain=gmail.com +root=username@gmail.com +AuthUser=username +AuthPass=password +``` + +Now install [GNU Mailutils][gnu-mailutils] (`sudo apt-get install mailutils` or the +equivalent on your OS), and send yourself your first email: + +```shell +echo body | mail -aFrom:email@example.com email@example.com -s subject +``` + +And that's about it, you've got mail. Here are some more places where it might +be applicable: + +```shell +# report a backup cronjob, attaching logs +set -e + +finish() { + status=$? + if [[ $status = 0 ]]; then + STATUS="SUCCESS (status $status)" + else + STATUS="FAILURE (status $status)" + fi + + mail user@example.com \ + -s "Backup job report on $(hostname): ${STATUS}" \ + --content-type 'text/plain; charset=utf-8' \ + -A"$LOG_FILE" <<< 'The log report is in the attachment.' +} +trap finish EXIT + +do-long-backup-cmd-here +``` + +``` +# share the output of a cmd with someone +some-program | mail someone@example.com -s "The weird logs that I was talking about" +``` + +...and so on. + +You may consider adding a `alias mail='mail -aFrom:email@example.com'` so you +don't keep re-entering the "From: " part. + +Send yourself some emails to see it working! + +[ssmtp]: https://wiki.archlinux.org/index.php/SSMTP +[gnu-mailutils]: https://mailutils.org/ +[forwarding-wiki-section]: https://wiki.archlinux.org/index.php/SSMTP#Forward_to_a_Gmail_mail_server diff --git a/src/content/tils/2020/09/05/oldschool-pr.adoc b/src/content/tils/2020/09/05/oldschool-pr.adoc new file mode 100644 index 0000000..5b4e445 --- /dev/null +++ b/src/content/tils/2020/09/05/oldschool-pr.adoc @@ -0,0 +1,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://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: + +```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 |