content: flesh out Git post some more

content/posts/how-i-use-git.md

@@ -8,9 +8,11 @@ tags = ["git"]
 title = "How I use Git"
 +++
 
-Every developer ends up using Git in some way or another these days, whether through the good old CLI or various Git GUI clients or the integrated options in their favorite IDEs. Because there are a myriad ways to use Git, and practically infinite extensibility, everyone internalizes patterns around how they work with Git. A favorite way of merging, a preferred pull strategy, and so on and so forth.
+Every developer ends up using Git in some way or another these days, whether through the good old CLI or various Git GUI clients or the integrated options in their favorite IDEs. Because there are a myriad ways to use Git, and practically infinite extensibility, everyone internalizes patterns around how they work with Git. A favorite way of merging, a preferred pull strategy, a bunch of shell aliases to save keystrokes, and so on and so forth.
 
-Over time I have developed habits around some of these patterns, augmented by features present within Git itself as well as external tools that integrate with Git.
+Over time I have also developed habits and patterns, augmented by features present within Git itself as well as external tools that integrate with Git.
+
+This post is going to be a overview of the tools I use with Git, and by extension GitHub, to make my daily workflow more productive.
 
 ## `.gitconfig`
 
@@ -18,13 +20,13 @@ The `.gitconfig` file is essentially the backbone of Git customisation. Any Git-
 
 > I say _files_, because Git includes a hierarchy of how Git settings take effect. Within a repository, settings are first looked up in `.git/config`, and then in `$HOME/.gitconfig` which allows having per-repository settings as necessary.
 
-My `.gitconfig` file can be found in my dotfiles [here][1]. I'll go over some of the less self-explanatory things here.
+My `.gitconfig` file can be found in my dotfiles [here][1]. Most of the settings keys are self-explanatory, the rest I'll go over below.
 
 - `core.pager` / `interactive.difffilter` switch my `git diff` and `git add --patch` views to use [diff-so-fancy][2].
 
 ![diff-so-fancy rendering the diff of a commit][3]
 
-- `pretty.fixes` adds a pretty format called `fixes` which lists commits in a format that is used by the Linux kernel developers to link to commits, the fixes for which they were committing.
+- `pretty.fixes` adds a ['pretty'][10] format called `fixes` which lists commits in the style that is used by the Linux kernel developers to link to the commits which introduced the bug they're fixing in their current commit. It adds a chain of historical reference to identify common bug patterns that are repeatedly occuring, which can then allow teams to devise ways of avoiding them.
 
 ```
 ➜ git log --pretty=fixes
@@ -50,9 +52,19 @@ Fixes: 1738364d2fdb ("Make password generator parameter changes reactive (#1480)
  10 months ago	origin/release
 ```
 
-- `log.follow` will track files through renames, relying on Git's in-built rename detection that it also uses for `git cherry-pick` and `git merge`.
+From this overview you can see that the `develop` branch of my fork is synced with the main APS repo, a release was made 3 days ago, and I was trying out Jetpack Compose 5 days ago for one of the app's screens.
+
+- `log.follow` will track files through renames, relying on Git's [in-built rename detection][11] that it also uses for `git cherry-pick` and `git merge`.
 
 ```
+# Without `log.follow`
+➜ git log --stat 3.txt
+commit 4f7bfdf35c1e544b1858e40fabfb26e33a91fde0 (HEAD -> main)
+...
+ 3.txt | 0
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+
+# With `log.follow`
 ➜ git log --stat 3.txt
 commit 4f7bfdf35c1e544b1858e40fabfb26e33a91fde0 (HEAD -> main)
 ...
@@ -70,18 +82,28 @@ commit 005e734a0018b2e8415d2be051c4e2b18e5feee3
  1 file changed, 1 insertion(+)
 ```
 
-## hub
+## `hub`
 
 Before GitHub had the [GitHub CLI][4], it had [hub][5]. `hub` wraps `git` and adds a bunch of extra niceties on top such as being able to do `git clone <repo>` to clone any of your own repositories. The one that I still use though, is `hub sync`, which fast-forwards all local checkouts of remote branches to the latest state on the remote.
 
-## git-absorb
+{{< asciinema oHZZ68hPpZdcTmiyI9n9k2XRF >}}
+
+## `git-absorb`
 
 [`git-absorb`][6] is a Git extension that mimics Mercurial's [`hg absorb`][7] extension, which inspects the currently staged changes and tries to look through your recent commits to determine which of them should your changes be amended to. More information on this can be found [here][8]
 
+// Add asciinema recording
+
 ## git-quickfix
 
 [`git-quickfix`][9] is another Git extension, which allows moving commits to a new branch quickly. The most common use case for it is this: Imagine you're working on a feature branch, and notice a small problem that is unrelated to your current branch. `git-quickfix` would allow you to make a commit on your current branch, then *move it to a new branch* in just one command.
 
+// Add asciinema recording
+
+## `gh`
+
+[`gh`][4] is GitHub's very own CLI for interacting with their platform. Since my day-to-day work revolves around GitHub, `gh` is extremely helpful is being able to triage issues, raise PRs, view the status of CI jobs and much more. Definitely a must-have if you're a terminal fiend and use GitHub!
+
 
 [1]: https://msfjarvis.dev/g/dotfiles
 [2]: https://github.com/so-fancy/diff-so-fancy
@@ -92,3 +114,5 @@ Before GitHub had the [GitHub CLI][4], it had [hub][5]. `hub` wraps `git` and ad
 [7]: https://www.mercurial-scm.org/wiki/Release4.8
 [8]: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercurial-4.8/
 [9]: https://github.com/siedentop/git-quickfix
+[10]: https://git-scm.com/docs/pretty-formats
+[11]: https://git-scm.com/docs/gitdiffcore#_diffcore_rename_for_detecting_renames_and_copies