Today I Learned

Using Markdown Image Titles as Captions

Sat, 31 Jan 2026 00:00:00 GMT

Today I learned that Markdown images support a title attribute that creates hover tooltips—and with a rehype plugin, you can transform these titles into captions.

Most people are familiar with the standard Markdown image syntax:

![Alt Text](/path/to/image.jpg)

Here, Alt Text serves as alternative text for accessibility—it appears when images fail to load and helps screen readers describe the image.

The path can be:

A relative path to a local file: ./images/photo.jpg
An absolute path: /assets/photo.jpg
A remote URL: https://example.com/photo.jpg

You can add a title attribute as a second parameter:

![Alt Text](/path/to/img.jpg "image title")

This creates a tooltip that appears when users hover over the image. You can also transform these titles into captions.

Markdown doesn’t natively support image captions, which leaves you with some awkward workarounds:

Option 1: Add text below the image using HTML tags:

![](image.png)
<sub><em>This is a caption for the image.</em></sub>

Option 2: Use raw HTML with <figure> elements:

<figure>
  <img src="image.png" alt="Example Image" width="200" height="200">
  <figcaption>This is a caption for the image.</figcaption>
</figure>

Both approaches work, but they break the flow of writing in plain Markdown.

If you’re writing a blog with a static site generator (like Astro, Next.js, or Gatsby), you can use a rehype plugin ¹ that transforms your image titles into captions.

With this plugin, you write clean Markdown:

![A descriptive alt text](./img.jpg "The caption")

And it becomes:

<figure class="rehype-figure-title">
  <img src="./img.jpg" alt="A descriptive alt text" />
  <figcaption>The caption</figcaption>
</figure>

Alternatives: rehype-title-figure or rehype-figure ↩

👉 Share this post: https://huam.ing/using-markdown-image-titles-as-captions

Git Pre-Commit Hooks Run Once per Commit, Not per File

Mon, 25 Aug 2025 00:00:00 GMT

Today I learned that Git’s pre-commit hook is executed/triggered once per commit, not once per file included in the commit.

If you want to restrict its behavior to certain files, you need to implement that logic inside your pre-commit script (for example, by checking git diff --cached --name-only to see which files are staged).

✼ Example 1: Strip YAML front matter from README.md

#!/bin/sh

if git diff --cached --name-only | grep -q '^README.md$'; then
    if head -n1 README.md | grep -q '^---$'; then
        sed '1,/^---$/d' README.md > README.md.tmp && mv README.md.tmp README.md
        git add README.md
    fi
fi

✼ Example 2: Run a Python script to update README.md

#!/bin/sh

if git diff --cached --name-only | grep -q '^README.md$'; then
    python3 .scripts/update_readme.py
    git add README.md
fi

By adding file-based checks, you can avoid unnecessary work and speed up commit performance, especially in large projects.

👉 Share this post: https://huam.ing/git-pre-commit-hooks-run-once-per-commit-not-per-file

How to Remove Markdown Frontmatter Programmatically

Sun, 24 Aug 2025 00:00:00 GMT

Today I learned how to strip out YAML frontmatter (--- … ---) from Markdown files using either Python or a shell script.

✼ Python approach

def remove_frontmatter(md_content):
  if md_content.startswith("---"):
    # Split the Markdown content into three parts
    # parts[0] = "" (before first ---)
    # parts[1] = YAML frontmatter
    # parts[2] = rest of the markdown
    parts = md_content.split("---", 2)
    if len(parts) > 2:
      return parts[2].lstrip("\n")
  return md_content

✼ Shell script approach

#!/bin/sh

if [ -f "$file" ] && head -n1 "$file" | grep -q '^---$'; then
  sed '1,/^---$/d' "$file" > "$file.tmp" && mv "$file.tmp" "$file"
fi

Key takeaway: Whether in Python or shell, the idea is the same—detect if the file starts with ---, then strip out everything up to the next ---.

👉 Share this post: https://huam.ing/how-to-remove-markdown-frontmatter-programmatically

Temporarily Ignore Local Changes to a Tracked File in Git

Fri, 22 Aug 2025 00:00:00 GMT

Today I learned that you can tell Git to temporarily ignore changes to a tracked file using:

git update-index --assume-unchanged <file>

After this, Git won’t show changes to the file in git status, git add, or git commit.

To start tracking changes again:

git update-index --no-assume-unchanged <file>

Caution

❗️ If the file is modified in the remote branch and you pull, Git may overwrite your local changes.
❗️ This is only for temporary local changes; the file remains tracked in the repository. This is mainly an optimization for large repositories, as Git will skip checking the file for changes, speeding up status and diff.

Side Notes

This is mainly an optimization for large repositories, as Git will skip checking the file for changes, speeding up status and diff.

👉 Share this post: https://huam.ing/temporarily-ignore-local-changes-to-a-tracked-file-in-git

How to Minimize Distractions in VS Code

Mon, 11 Aug 2025 00:00:00 GMT

Today I learned how to minimize distractions in VS Code.

Use Zen Mode

Activate Zen Mode with Cmd+K Z.
- Or from the Command Palette → “View: Toggle Zen Mode”.
Press Cmd+K Z again to exit Zen Mode.

Hide UI Elements

Hide the sidebar (Cmd+B).
Hide the panel (Cmd+J).
Hide the status bar (Cmd+Shift+P → “View: Toggle Status Bar Visibility”).
Hide the breadcrumbs via Cmd+Shift+P → “View: Toggle Breadcrumbs”.
- Alternatively, you can add this line to settings.json:
```
"breadcrumbs.enabled": false
```
Hide the minimap via Cmd+Shift+P → “View: Toggle Minimap”.
- Alternatively, you can add this line to settings.json:
```
"editor.minimap.enabled": false
```

Hide the scroll bar:

"editor.scrollbar.horizontal": "hidden",
"editor.scrollbar.vertical": "hidden"

Hide the overview ruler:

"editor.hideCursorInOverviewRuler": true

👉 Share this post: https://huam.ing/how-to-minimize-distractions-in-vs-code

Handling Case-Sensitive File Renames in Git

Fri, 08 Aug 2025 00:00:00 GMT

The Problem

Today I ran into a frustrating Git issue that I’d never encountered before. I had renamed several image files in my Obsidian vault’s _attachments folder, changing their extensions from uppercase (.PNG, .JPG, .WEBP) to lowercase (.png, .jpg, .webp).

However, when I tried the usual workflow:

git add .
git commit -m "Fix file extensions"
git push

Git didn’t detect any changes, even though I could clearly see the files had different extensions on my filesystem.

The Root Cause

The issue stems from macOS having a case-insensitive filesystem while Git is case-sensitive.

From the filesystem’s point of view, image.PNG and image.png are the same file, but Git sees them as different files.

This caused a mismatch where Git was still tracking the old uppercase extensions in its index, even though the filesystem only showed the lowercase files.

As a result, Git doesn’t realize the file has been renamed because the filesystem treats both names as identical.

The Solution: `git mv`

The solution is to use git mv to explicitly tell Git about the change. The git mv command renames the file both in your filesystem and Git’s index, so Git can track the rename as a single operation:

# Instead of manually renaming files, use git mv
git mv oldfile.PNG newfile.png
git mv image.JPG image.jpg
git mv photo.WEBP photo.webp

What I Did

I had to rename several files that Git was tracking with uppercase extensions:

cd "/path/to/my/repo"

# First, find out which files with uppercase extensions Git is tracking
git ls-files _attachments/ | grep -E "\.(PNG|JPG|WEBP)$"

# Then rename each one using git mv
git mv _attachments/2b3a6c702b5b01cf12507cc029630bf3.JPG _attachments/2b3a6c702b5b01cf12507cc029630bf3.jpg
git mv _attachments/316d587a5c95f54ea7a4f86fbb986d63.PNG _attachments/316d587a5c95f54ea7a4f86fbb986d63.png
git mv _attachments/33fabea8972383bcb4bbeea50437f690.PNG _attachments/33fabea8972383bcb4bbeea50437f690.png
# more attachments...

# Commit the changes
git commit -m "Rename image file extensions from uppercase to lowercase"
git push

Alternative Solutions

Other approaches I could have used (but git mv is cleanest and simplest):

Configure Git to ignore case (not recommended):
Terminal window
```
git config core.ignorecase false
```
Remove and re-add (loses history):
Terminal window
```
git rm file.PNG
git add file.png
```
In contrast, when you use git mv, Git properly records the change as a rename:
Terminal window
```
# Git status showed:
renamed: _attachments/image.PNG -> _attachments/image.png
```

👉 Share this post: https://huam.ing/handling-case-sensitive-file-renames-in-git

Git Reset

Thu, 24 Jul 2025 00:00:00 GMT

Today I learned how to use git reset to undo changes in my repository.

Introduction

git reset is used to undo changes in your Git repository. It allows you to move the current branch to a specific commit and control what happens to your staging area and working directory. git reset is especially useful when you want to undo commits that have not been pushed to a remote repository.

When to Use

Use git reset --soft <commit> to move the branch pointer back and keep your changes staged for a new commit.
Use git reset --mixed <commit> (or simply git reset <commit>, since --mixed is the default) to remove files from the staging area but keep changes in your working directory.
Use git reset --hard <commit> to completely discard all changes in both the staging area and working directory.
- ⚠️ Dangerous! This will delete all uncommitted changes and is irreversible!

Overview

Mode	Affects Commit History	Affects Staging Area	Affects Working Directory
`--soft`	✅ Yes	❌ No	❌ No
`--mixed`	✅ Yes	✅ Yes	❌ No
`--hard`	✅ Yes	✅ Yes	✅ Yes

Summary

--soft: Only resets commit history, keeps staging area and working directory unchanged.
--mixed: Resets commit history and staging area, keeps working directory unchanged.
--hard: Resets everything, including working directory.

👉 Share this post: https://huam.ing/git-reset

Git Commit Messages from a File

Sun, 20 Jul 2025 00:00:00 GMT

Today I learned that there are two main ways to provide a commit message in Git:

-m <msg> or --message=<msg>: This is the most common way, where you provide the message directly on the command line. You can use multiple -m options, and their values will be concatenated as separate paragraphs.
-F <file> or --file=<file>: This option allows you to take the commit message from a given file. If you use - as the filename, the message is read from the standard input. This is particularly useful for multi-line messages as it avoids potential issues with shell character escaping.

It’s important to note that the -m and -F options are mutually exclusive. You can only use one of them for a single commit.

✱ Example using -F

Create a file named commit-message.txt:

feat: Add new login feature

This commit introduces a new login system with email and password authentication.
It also includes basic validation and error handling.

Use the file in your commit command:
Terminal window
```
git commit -F commit-message.txt
```

👉 Share this post: https://huam.ing/git-commit-messages-from-a-file

VS Code CLI & URL Schemes

Sun, 20 Jul 2025 00:00:00 GMT

Today I learned that Visual Studio Code has a powerful command-line interface (CLI) that lets you control how you launch the editor through command-line options (switches).

Opening Files and Folders

Open a file: code <file_path>. You can list multiple files separated by spaces. If a file doesn’t exist, it will be created. When opening multiple files, VS Code opens them all as tabs in a single window instance.
Open a folder: code <folder_path>. You can specify multiple folders separated by spaces to create a Multi-root Workspace that includes each folder and allows you to manage multiple project “roots” simultaneously.

Common CLI Options

Go to File Location 1

Open a file at a specific line and optional column.

code -g, --goto path/to/file:line[:column]

New Window

Open a fresh session of VS Code instead of restoring the previous session.

code -n, --new-window [path/to/folder-or-file]

You can also use -r or --reuse-window to force opening a file or folder in the last active window.

Wait for Close

Wait for the opened file to be closed before returning to the command line. This is useful for things like editing a Git commit message.

code -w, --wait path/to/file

Use a Specific Profile

Specify the directory for user data, which is useful for managing separate profiles or running as a different user.

code --user-data-dir "/path/to/custom/profile"

Disable Extensions

Open VS Code with all installed extensions temporarily disabled.

code --disable-extensions

Verbose Logging

Enables verbose logging, which is helpful for diagnosing issues.

code --verbose

Show Help

Displays all available CLI options.

code --help

Alternatively, you can view the manual page:

man code

URL Schemes

You can also use vscode:// URL schemes to open folders and files.

Open a Folder

vscode://file/{full path to folder}/

Open a File

vscode://file/{full path to file}

Open a File to a Specific Line and Column

vscode://file/{full path to file}:line:column

The column number for character position is optional. ↩

👉 Share this post: https://huam.ing/vs-code-cli-and-url-schemes

How to Write Good Git Commit Messages

Sat, 19 Jul 2025 00:00:00 GMT

Today I learned how to write structure, easy-to-communicate commit messages in Git.

Why?

A clear, consistent commit message format helps:

Quickly understand project history
Filter and find specific changes (e.g. documentation vs code)
Generate changelogs automatically (see below for details)

Recommended Format

Use the Conventional Commits standard:

<type>(<scope>): <description>

[optional body]

[optional footer]

Type	Description
`feat`	New feature
`fix`	Bug fix
`docs`	Documentation changes
`style`	Formatting, whitespace, etc. (no code change)
`refactor`	Code refactor (no bug fix or feature)
`perf`	Performance improvement
`test`	Adding or updating tests
`chore`	Routine tasks (build, dependencies, etc.)

Helper Tools

Tool	What It Does	When It’s Used
commitizen	Interactive CLI that guides you through writing a commit message	Before writing commits
commitlint	Lints commit messages to ensure they meet the standard and enforce consistency ¹	After writing commits
conventional-changelog	Automatically generates changelogs from commit history	After merging/releasing

Example workflow:

Write commits using the Conventional Commits format.
Run npx conventional-changelog -i CHANGELOG.md -s to update your changelog.

This command scans your commit history for Conventional Commits, generates a changelog, writes it to CHANGELOG.md (-i CHANGELOG.md), and updates the file in place (-s). The default preset is Angular, but you can omit -p angular for most projects.

💡 To see all available command line parameters, run: conventional-changelog --help
Optionally, use standard-version or release-it to bump versions and update changelogs automatically.

You can add a Git hook (commit-msg) to validate your commit messages: npx commitlint --edit $1 ↩

👉 Share this post: https://huam.ing/how-to-write-good-git-commit-messages

YouTube URL Schemes

Thu, 17 Jul 2025 00:00:00 GMT

Today I learned how to customize YouTube URL schemes to make video sharing more effective:

Watch Links
- Format
  - Regular version: https://www.youtube.com/watch?v=<video_id>
  - Short version: https://youtu.be/<video_id>
- Query parameters
  - t → Starts the video at a specific timestamp, great for directly jumping to the key moments
    - For example:
      - &t=60 starts the video 1 minute in
      - &t=1m30s starts the video 1 minute and 30 seconds in
    - Works for both watch link types:
      - https://www.youtube.com/watch?v=cnQLp_DII2o&t=120
      - https://youtu.be/cnQLp_DII2o?t=120
  - The following parameters are unnecessary and can be safely stripped from URLs:
    - list → Shows which playlist the video is from
      - Example: &list=PLVELbpBnqC0qFKrWNBZupOEV6MX4xt_fM
    - ab_channel → Shows which channel the video is from
      - Example: &ab_channel=InspiringSquad
  - https://www.youtube.com/embed/<video_id>
    - Use this to embed videos on websites ¹
    - ⭐️ Also, this is helpful for watching videos without any ads!
    - Example: https://www.youtube.com/watch?v=NcQQVbioeZk → https://www.youtube.com/embed/NcQQVbioeZk
Playlist Links
- Format: https://www.youtube.com/playlist?list=<playlist_id>
Channel Links
- Format: https://www.youtube.com/channel/@<channel_handle>

https://developers.google.com/youtube/player_parameters ↩

👉 Share this post: https://huam.ing/youtube-url-schemes

GitHub URL Schemes for Viewing, Editing, and Commit History

Wed, 16 Jul 2025 00:00:00 GMT

Today I learned that GitHub provides several URL schemes for different file operations.

For viewing files, use: ¹
```
https://github.com/{owner}/{repo}/blob/{branch}/{file_path}
```
Example: https://github.com/huaminghuangtw/Today-I-Learned/blob/main/posts/github-url-schemes.md
To view raw content, use:
```
https://raw.githubusercontent.com/{owner}/{repo}/{branch}/{file_path}
```
Example: https://raw.githubusercontent.com/huaminghuangtw/Today-I-Learned/main/posts/github-url-schemes.md
When you need to modify content, use:
```
https://github.com/{owner}/{repo}/edit/{branch}/{file_path}
```
Example: https://github.com/huaminghuangtw/Today-I-Learned/edit/main/posts/github-url-schemes.md

Both view and edit URLs support #Lx suffix for jumping to specific lines. Edit URLs require login to save changes, while view URLs are public. The key difference is that edit URLs are for proposing changes and editing content, while view URLs are for sharing lines and viewing raw files.
Finally, to explore version history, use:
```
https://github.com/{owner}/{repo}/commits/{branch}/{file_path}
```
Example: https://github.com/huaminghuangtw/Today-I-Learned/commits/main/posts/github-url-schemes.md

With Markdown files (.md), GitHub automatically adds the plain=1 query parameter when you go to Code view to get a line permalink, because Markdown files are rendered without line numbers in Preview mode. For code files (.js, .py, .txt, etc.), you get syntax highlighting without the plain=1 parameter. ↩

👉 Share this post: https://huam.ing/github-url-schemes-for-viewing-editing-and-commit-history

Git Tags

Thu, 23 Jan 2025 00:00:00 GMT

Today I learned that Git tags are like bookmarks pointing to a specific commit. They are commonly used to mark important milestones, such as production releases.

Why?

Mark release snapshots (e.g., v1.0.0)
Track significant changes
Simplify version management

Types

Lightweight (default):
- Just a name for a commit (like a branch that never moves)
Annotated (recommended):
- Checksummed, including metadata (date, tagger, message, optional GPG signature)
- Stored as full objects in the Git database

Cheat Sheet

Command	Note
`git tag [-a] v1.0.0 [<commit_id>] [-m <msg>]`	Create a tag (annotated with `-a` and `-m`)
`git tag <tag_name> HEAD`	Tag the latest commit
`git checkout <tag_name>`	Check out a tag
`git tag`	List all tags
`git tag -l "v1.1.*"`	Filter tags by pattern
`git show <tag_name>`	Show tag details
`git push origin <tag_name>`	Push a tag to remote (tags are not pushed by default)
`git push origin --tags`	Push all tags to remote
`git push --follow-tags`	Push only annotated tags
`git tag --delete <tag_name>`	Delete a local tag
`git tag \| xargs git tag -d`	Delete all local tags
`git push --delete origin <tag_name>`	Delete a remote tag
`git tag \| xargs -n 1 git push origin --delete`	Delete all remote tags

👉 Share this post: https://huam.ing/git-tags