[bin+brew] `?brew-changelog?`: Explore ways to display CHANGELOGs for `brew outdated` / `gh outdated` / similar

[0xdevalias]

It would be useful to be able to easily see / review CHANGELOG entries when using brew outdated, or after a brew update / before a brew upgrade, etc.

Prior Art

• brew changelog $package should open the changelog  Homebrew/brew#3399

  • brew changelog $package should open the changelog

  • For this to be a thing it would need to be built like brew desc was: a community would need to amass these URLs for every (relevant) package in Homebrew in an external command in a third party tap and we'd consider merging it into Homebrew proper after that process is complete.

• https://github.com/Homebrewery/homebrew-changelog

  • Homebrew changelog

    Following on from Homebrew/brew#3399, this is an effort to introduce a changelog stanza into Homebrew formulae and Casks.

    Hopefully this will follow the process of the description stanza, and so initially this will be in the from of an external command, made available with this tap…

    Note that a /changelogs.y[a]ml file can be added to the [Formula/Casks] folder of any tap to also work with this command.

  • Contributions for changelog URLs are very welcome, and extremely easy to add! Just a line of YAML in either formulae.yml or casks.yml. Be sure to remove the http[s]://[www.] portion, and any trailing / or .html suffix from the URL, unless necessary, as these will automatically be resolved.

• https://github.com/ltaupiac/brewclog

  • brewclog

  • Display the Last Changelog of a Brew Formula

  • https://github.com/ltaupiac/brewclog/blob/main/functions/brewclog.fish

My Approach

Here is the exploration / approach that I wrote up in the following issue:

• Alternative approach: Dynamically identify/fetch CHANGELOGs Homebrewery/homebrew-changelog#20

As an alternative approach to needing to statically identify the CHANGELOGs for tools up front; I was thinking for a lot of things (particularly those hosted on GitHub), there are common patterns of a CHANGELOG.md file in the repo root, or using GitHub Releases, etc; that could allow us to more dynamically fetch the details (which might also mean a quicker path to adoption in core with less potential Homebrew maintainer burden/etc: Homebrew/brew#3399)

As a starting point, I stumbled on this other tool by @ltaupiac that seems to have a similar sort of goal, focussed purely on GitHub, and written in fish shell scripts:

• https://github.com/ltaupiac/brewclog

  • brewclog

  • Display the Last Changelog of a Brew Formula

  • https://github.com/ltaupiac/brewclog/blob/main/functions/brewclog.fish

It basically seems to do the following:

• Tries brew ruby -e "Formula['name'].head.url" to get the repo URL.
• Falls back to brew info --json=v2 to extract the homepage if the head URL isn’t available
  • brew info --json=v2 "$formula_name" | jq -r '.formulae[]?.homepage // empty, .casks[]?.homepage // empty'
• Cleans up .git suffix if present
  • set repo (echo $repo | sed 's#\.git$##')
• Only continues if the repo host is github.com; otherwise, exits with a message that only GitHub is supported.
  • set -l current_host (trurl --get {host} "$repo")

  • if test "$current_host" != "github.com"
      # ..snip..
    end
    

• Appends /releases/latest to the repo URL.
  • set repo (echo $repo | sed 's#$#/releases/latest#')
• Rewrites host to api.github.com.
  • set repo (trurl --set host='api.github.com' $repo)
• Adjusts the path to prefix with /repos/..., turning it into the correct GitHub API endpoint for the latest release.
  • set -l extracted_path (trurl --get {path} "$repo")
  • set -l path "/repos$extracted_path"
  • set -l repo (trurl --set path="$path" "$repo")
• Performs a curl request to the GitHub API endpoint, extracts .tag_name and .body from the JSON using jq, pipes that through glow -p to render the changelog nicely in the terminal.
  • curl -s "$repo" | jq -r '.tag_name, .body' | glow -p
    • https://github.com/charmbracelet/glow

---

If I was going to approach trying to solve this from scratch today myself, I would probably largely rely on the GitHub CLI gh for the 'heavy lifting', as well as relevant API endpoints:

• https://cli.github.com/
• https://github.com/cli/cli

  • GitHub CLI

  • GitHub’s official command line tool

  • gh is GitHub on the command line. It brings pull requests, issues, and other GitHub concepts to the terminal next to where you are already working with git and your code.

• https://docs.github.com/en/rest/repos/contents#get-repository-content

  • Get repository content

  • Gets the contents of a file or directory in a repository. Specify the file path or directory with the path parameter. If you omit the path parameter, you will receive the contents of the repository's root directory.

  • gh api repos/OWNER/REPO/contents/CHANGELOG.md
  • gh api repos/OWNER/REPO/contents/CHANGELOG.md --jq '{ name, content, encoding, html_url, download_url }'

  • gh api repos/OWNER/REPO/contents/CHANGELOG.md \
      --jq '{
        name,
        html_url,
        download_url,
        encoding,
        content: (if .encoding == "base64" then (.content | @base64d) else .content end)
      }
      | if .encoding == "base64" then del(.encoding) else . end'

If we wanted to render markdown nicely in the terminal ourself, we could use:

• https://github.com/charmbracelet/glow

And then for releases...

We can list them:

List releases in a repository

For more information about output formatting flags, see `gh help formatting`.

USAGE
  gh release list [flags]

ALIASES
  gh release ls

FLAGS
      --exclude-drafts         Exclude draft releases
      --exclude-pre-releases   Exclude pre-releases
  -q, --jq expression          Filter JSON output using a jq expression
      --json fields            Output JSON with the specified fields
  -L, --limit int              Maximum number of items to fetch (default 30)
  -O, --order string           Order of releases returned: {asc|desc} (default "desc")
  -t, --template string        Format JSON output using a Go template; see "gh help formatting"

INHERITED FLAGS
      --help                     Show help for command
  -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format

JSON FIELDS
  createdAt, isDraft, isLatest, isPrerelease, name, publishedAt, tagName

..snip..

We can see a scrollable list like this:

gh release list --repo OWNER/REPO

Or we could list releases (up to the limit) as JSON like this:

gh release list --exclude-drafts --exclude-pre-releases --repo OWNER/REPO --json 'createdAt,publishedAt,isLatest,name,tagName'

And filter those to only ones after a specified version like this:

AFTER_TAG="4.6.9"

gh release list \
  --exclude-drafts --exclude-pre-releases \
  --repo Homebrew/brew \
  --json 'createdAt,publishedAt,isLatest,name,tagName' \
  --jq '
    def norm: ltrimstr("v");
    def ver: split(".") | map(tonumber);

    map(select((.tagName // .name | norm | ver) > ("'"$AFTER_TAG"'" | norm | ver)))
  '

And then we can view information about the releases too:

View information about a GitHub Release.

Without an explicit tag name argument, the latest release in the project
is shown.

For more information about output formatting flags, see `gh help formatting`.

USAGE
  gh release view [<tag>] [flags]

FLAGS
  -q, --jq expression     Filter JSON output using a jq expression
      --json fields       Output JSON with the specified fields
  -t, --template string   Format JSON output using a Go template; see "gh help formatting"
  -w, --web               Open the release in the browser

INHERITED FLAGS
      --help                     Show help for command
  -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format

JSON FIELDS
  apiUrl, assets, author, body, createdAt, databaseId, id, isDraft, isPrerelease,
  name, publishedAt, tagName, tarballUrl, targetCommitish, uploadUrl, url,
  zipballUrl

..snip..

Such as:

• Latest release in terminal: gh release view --repo OWNER/REPO
• Latest release on web: gh release view --repo OWNER/REPO --web
• Specific release in terminal: gh release view --repo OWNER/REPO 1.2.3
• Specific release on web: gh release view --repo OWNER/REPO 1.2.3 --web
• We could also get various parts of that as JSON/etc if we wanted, but that seems less relevant here
  • If we wanted to render markdown nicely in the terminal ourself, we could use: https://github.com/charmbracelet/glow

So then we could also combine that together by using fzf or similar; so that we can browse through the various releases, and preview/open their CHANGELOG in the browser:

OWNER="Homebrew"; \
REPO="brew"; \
AFTER_TAG="4.6.9"; \
\
gh release list \
  --exclude-drafts --exclude-pre-releases \
  --repo "$OWNER/$REPO" \
  --json 'tagName,name,createdAt,publishedAt' \
  --jq 'def norm: ltrimstr("v");
        def ver: split(".") | map(tonumber);

        (["TAG","NAME","CREATED","PUBLISHED"]),
        (map(select((.tagName // .name | norm | ver) > ("'"$AFTER_TAG"'" | norm | ver)))
         | map([.tagName, .name, .createdAt, .publishedAt])[])
        | @tsv' \
| column -ts $'\t' \
| FZF_DEFAULT_COMMAND= \
  fzf \
    --prompt "Releases> " \
    --info=inline-right \
    --input-border \
    --header-lines=1 \
    --footer $'Enter: View in Terminal    Ctrl-O: Open in Browser    Ctrl-P: Toggle Preview' \
    --footer-border=line \
    --reverse \
    --delimiter='[[:space:]]{2,}' \
    --nth '1..' \
    --with-nth '1..' \
    --accept-nth 1 \
    --preview 'GH_FORCE_TTY=1 gh release view --repo '"$OWNER/$REPO"' {1}' \
    --preview-window 'right,60%,border-left,wrap,hidden' \
    --bind 'enter:execute(gh release view --repo '"$OWNER/$REPO"' {1})' \
    --bind 'ctrl-o:execute-silent(gh release view --repo '"$OWNER/$REPO"' {1} --web)+abort' \
    --bind 'ctrl-p:toggle-preview'

And with a bit more effort, we could also make a way that can neatly choose the releases or the CHANGELOG.md depending on which is better.

Originally posted by @0xdevalias in Homebrewery/homebrew-changelog#20

Other Things We Could Improve

This could be a useful addition to my gh outdated alias:

dotfiles/config.symlink/gh/config.yml

Lines 76 to 145 in 8d8551a

	outdated: |
	!gh_extensions_outdated() {
	if [ "$1" = "-h" ] || [ "$1" = "--help" ] || [ $# -ne 0 ]; then
	echo "Usage: gh outdated"
	echo "Check for outdated GitHub CLI extensions and the gh CLI tool itself."
	echo ""
	echo "This command performs the following actions:"
	echo " - Lists all installed gh extensions."
	echo " - Checks if any installed extensions have updates available."
	echo " - Offers to upgrade individual extensions if updates are available."
	echo " - Checks if the gh CLI tool is up to date and offers to upgrade it if not."
	echo ""
	echo "Options:"
	echo " -h, --help Show this help message and exit."
	return 0
	fi
	gh extension list
	echo
	echo "Release notes:"
	(gh extension list | awk '{print $3}' | sed 's#^# https://github.com/#' | sed 's#$#/releases#')
	echo
	echo "Checking for outdated extensions..."
	outdated_extensions=$(gh extension upgrade --all --dry-run)
	outdated_found=false
	while read -r line; do
	if [[ $line == *"would have upgraded from"* ]]; then
	outdated_found=true
	extension_name=$(echo "$line" | awk '{print $1}' | tr -d '[]:')
	current_version=$(echo "$line" | awk '{print $(NF-2)}')
	new_version=$(echo "$line" | awk '{print $NF}')
	echo " Extension $extension_name is outdated (Current: $current_version, Available: $new_version)"
	# echo "Do you want to upgrade $extension_name? [y/N]"
	# read -r upgrade_extension
	# if [ "$upgrade_extension" = "y" ]; then
	# gh extension upgrade "$extension_name"
	# fi
	fi
	done <<< "$outdated_extensions"
	if [[ $outdated_found == true ]]; then
	echo "Do you want to upgrade all outdated extensions? [y/N]"
	read -r answer
	if [ "$answer" = "y" ]; then
	gh extension upgrade --all
	fi
	else
	echo " All extensions are up to date!"
	fi
	echo
	echo "Checking to see if gh is up to date..."
	if brew outdated gh | grep -q 'gh'; then
	echo "gh is outdated. Do you want to upgrade? [y/N]"
	read -r upgrade_gh
	if [ "$upgrade_gh" = "y" ]; then
	brew upgrade gh
	fi
	else
	echo " gh is up to date!"
	fi
	}; gh_extensions_outdated $@

Which currently has some crude URL manipulation for showing release notes:

dotfiles/config.symlink/gh/config.yml

Lines 97 to 98 in 8d8551a

	echo "Release notes:"
	(gh extension list | awk '{print $3}' | sed 's#^# https://github.com/#' | sed 's#$#/releases#')

See Also

• [bin+brew] brew-upgrade-safe: Explore safer brew upgrade helper to prevent cascading dependent upgrades #33
• https://docs.brew.sh/External-Commands
• https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap

[0xdevalias]

Tangentially related exploration:

• https://github.com/charmbracelet/glow

  • Glow

  • Render markdown on the CLI, with pizzazz!

• https://github.com/charmbracelet/glamour

  • Glamour

  • Stylesheet-based markdown rendering for your CLI apps.

Me:

What does the code behind gh release view --repo Homebrew/brew 4.6.10 use for rendering the markdown in the terminal? Is it glow, or something like it?

GitHub Copilot (GPT-5):

Short answer: it uses Charmbracelet’s Glamour, not Glow.

Details and pointers:

• The CLI’s Markdown renderer is a thin wrapper around Glamour:
  • pkg/markdown/markdown.go imports github.com/charmbracelet/glamour and delegates to github.com/cli/go-gh/v2/pkg/markdown, which in turn uses Glamour for terminal rendering:
    https://github.com/cli/cli/blob/6b19a854710ff2c81070f109f35434cd20e40115/pkg/markdown/markdown.go#L1-L40
• Environment controls reference Glamour directly:
  • GLAMOUR_STYLE is documented in the built-in help:
    https://github.com/cli/cli/blob/6b19a854710ff2c81070f109f35434cd20e40115/pkg/cmd/root/help_topic.go#L72-L114
  • Terminal theme detection defers to GLAMOUR_STYLE and the terminal’s light/dark background:
    https://github.com/cli/cli/blob/6b19a854710ff2c81070f109f35434cd20e40115/pkg/iostreams/iostreams.go#L117-L160
• The dependency list confirms Glamour is bundled:
  • third-party-licenses.*.md include github.com/charmbracelet/glamour:
    macOS: https://github.com/cli/cli/blob/6b19a854710ff2c81070f109f35434cd20e40115/third-party-licenses.darwin.md#L40-L54
    Linux: https://github.com/cli/cli/blob/6b19a854710ff2c81070f109f35434cd20e40115/third-party-licenses.linux.md#L39-L53

Practically, commands that render Markdown (e.g., repo view, PR comments) call this same markdown.Render(...) pipeline with options like WithTheme(io.TerminalTheme()) and WithWrap(...). Release notes use the same path, so gh release view renders via Glamour as well.

Useful knobs:

• GLAMOUR_STYLE to pick a style (see Glamour styles)
• GH_MDWIDTH to cap wrapping width
• Automatic light/dark theme is chosen based on terminal background unless GLAMOUR_STYLE overrides it

Note: these code search results may be incomplete. You can explore more matches here:

• Search “glamour” in cli/cli: https://github.com/search?q=repo%3Acli%2Fcli+glamour&type=code
• Search “markdown.Render” in cli/cli: https://github.com/search?q=repo%3Acli%2Fcli+markdown.Render&type=code

Me:

Does glow use glamour? Or?

GitHub Copilot (GPT-5):

Yes. Glow uses Charmbracelet’s Glamour to render Markdown in the terminal.

Evidence from the Glow repo:

• main.go initializes a Glamour term renderer and renders content with it:
  • glamour.NewTermRenderer(...), r.Render(content) [main.go]
• The TUI pager path renders via Glamour as well:
  • glamourRender(...), glamour.NewTermRenderer(options...) [ui/pager.go]
• Utilities explicitly select Glamour styles and options:
  • utils.GlamourStyle(...), returns glamour.TermRendererOption [utils/utils.go]
• go.mod depends on github.com/charmbracelet/glamour [go.mod]
• Config exposes GLAMOUR_STYLE and toggles GLOW_ENABLE_GLAMOUR [ui/config.go]

Direct links to referenced files:

• main.go (render path): https://github.com/charmbracelet/glow/blob/a440b3319bc466be6d249c564d0c5f43fe14da57/main.go#L270-L383
• ui/pager.go (TUI render path): https://github.com/charmbracelet/glow/blob/a440b3319bc466be6d249c564d0c5f43fe14da57/ui/pager.go#L381-L485
• utils/utils.go (style helpers): https://github.com/charmbracelet/glow/blob/a440b3319bc466be6d249c564d0c5f43fe14da57/utils/utils.go#L1-L113
• go.mod (dependency): https://github.com/charmbracelet/glow/blob/a440b3319bc466be6d249c564d0c5f43fe14da57/go.mod#L1-L49
• ui/config.go (env config): https://github.com/charmbracelet/glow/blob/a440b3319bc466be6d249c564d0c5f43fe14da57/ui/config.go#L1-L20

Note: code search results may be incomplete. Explore more references here:

• Search “glamour” in glow: https://github.com/search?q=repo%3Acharmbracelet%2Fglow+glamour&type=code

[0xdevalias]

Draft Plan for a gh Release Notes / CHANGELOG Browser Helper Script

The following plan was created by GitHub Copilot (GPT-5) based on a reference to this issue and the following prompt:

Can you write up a quick draft plan for how we could take the final fzf command in 'My Approach' above, and clean it up into a nicely formatted zsh helper script in my dotfiles/bin; that follows my existing patterns for those scripts.

To basically draft a plan to turn the following prototype into something more polished:

OWNER="Homebrew"; \
REPO="brew"; \
AFTER_TAG="4.6.9"; \
\
gh release list \
  --exclude-drafts --exclude-pre-releases \
  --repo "$OWNER/$REPO" \
  --json 'tagName,name,createdAt,publishedAt' \
  --jq 'def norm: ltrimstr("v");
        def ver: split(".") | map(tonumber);

        (["TAG","NAME","CREATED","PUBLISHED"]),
        (map(select((.tagName // .name | norm | ver) > ("'"$AFTER_TAG"'" | norm | ver)))
         | map([.tagName, .name, .createdAt, .publishedAt])[])
        | @tsv' \
| column -ts $'\t' \
| FZF_DEFAULT_COMMAND= \
  fzf \
    --prompt "Releases> " \
    --info=inline-right \
    --input-border \
    --header-lines=1 \
    --footer $'Enter: View in Terminal    Ctrl-O: Open in Browser    Ctrl-P: Toggle Preview' \
    --footer-border=line \
    --reverse \
    --delimiter='[[:space:]]{2,}' \
    --nth '1..' \
    --with-nth '1..' \
    --accept-nth 1 \
    --preview 'GH_FORCE_TTY=1 gh release view --repo '"$OWNER/$REPO"' {1}' \
    --preview-window 'right,60%,border-left,wrap,hidden' \
    --bind 'enter:execute(gh release view --repo '"$OWNER/$REPO"' {1})' \
    --bind 'ctrl-o:execute-silent(gh release view --repo '"$OWNER/$REPO"' {1} --web)+abort' \
    --bind 'ctrl-p:toggle-preview'

The draft plan output (which I haven't manually refined) is captured below:

Below is a concise draft plan to turn your final fzf pipeline into a polished zsh helper script that matches your dotfiles/bin conventions.

Note: the bin/ file list I fetched may be incomplete; browse the full directory here to confirm patterns you prefer:
https://github.com/0xdevalias/dotfiles/tree/devalias/bin

What I inferred from your bin/

• Naming: many task-oriented, kebab-case helpers (e.g., gh-..., git-..., ez-..., brew-...).
• Shell helpers: lean simple and focused, often single-file utilities.
• You already have several GitHub-centric helpers (gh-*) and Homebrew helpers (brew-*), so either naming family would be consistent.

Proposed script

• Name options (pick what feels most “you”):
  • brew-changelog-browse
  • gh-releases-browse
  • brew-releases-browse
• Location: dotfiles/bin/<chosen-name>
• Shebang: #!/usr/bin/env zsh
• Safety/strict mode:

  set -o errexit -o nounset -o pipefail

• Dependencies: gh, fzf, jq, column (bsd column is fine), sed/awk, glow (optional for pretty markdown), brew (for formula→repo resolution)
• Input modes:
  • Mode A (GitHub-native): Accept OWNER/REPO directly.
  • Mode B (Homebrew-aware): Accept a Homebrew formula or cask name, resolve to OWNER/REPO.
• Output modes:
  • Releases mode (default): interactive fzf list of releases with preview.
  • Changelog mode: fetch and render CHANGELOG.* from repo root (fallback to Releases if not found).
• Filters:
  • After-tag filter: only show releases newer than a given tag (strip leading v; compare semver segments).
  • Include/exclude pre-releases; include/exclude drafts.

Usage and flags (draft)

<script> [-r OWNER/REPO | -f FORMULA] [-a AFTER_TAG] [--include-pre] [--include-drafts] [--web] [--mode {releases|changelog}] [--limit N]

• -r OWNER/REPO: use a GitHub repo directly
• -f FORMULA: resolve GitHub repo via Homebrew
• -a AFTER_TAG: only show releases newer than this tag (e.g., 4.6.9 or v4.6.9)
• --include-pre / --include-drafts: opt-in to pre-releases/drafts
• --web: default Enter opens browser instead of terminal view
• --mode: choose releases (default) or changelog
• --limit: gh release list limit (default 100)
• -h/--help: print usage

Flow

1. Parse flags and validate inputs. Require one of -r or -f.
2. Resolve OWNER/REPO:
   • If -r given, normalize (strip trailing .git).
   • If -f given, attempt:
     a) brew ruby -e "Formula['<name>'].head.url" (if available)
     b) Else: brew info --json=v2 | jq homepage; if GitHub URL, convert to owner/repo.
     c) Guardrail: if host != github.com, exit with friendly message.
3. If --mode=changelog:
   • Try GitHub Contents API via gh: repos/:owner/:repo/contents/CHANGELOG.md
     (and common variants: CHANGELOG, CHANGES, ReleaseNotes, RELEASE_NOTES)
   • If found, decode content (base64) and:
     • If glow present: echo content | glow -p
     • Else: less -R or just print
   • If not found, fall back to releases mode with informational message.
4. Releases mode:
   • Build gh release list command:

     gh release list --repo OWNER/REPO \
       --exclude-drafts (unless included) \
       --exclude-pre-releases (unless included) \
       --json 'tagName,name,createdAt,publishedAt' \
       -L $LIMIT

   • Apply jq filter for AFTER_TAG:
     • strip leading v; split on dots; coerce to numbers; compare arrays
   • Produce tabular TSV with header row; pipe to column -ts $'\t'
5. fzf UI:
   • Prompt: Releases>
   • Header lines: 1 (the header row)
   • Footer:

     Enter: View in Terminal    Ctrl-O: Open in Browser    Ctrl-P: Toggle Preview
     

   • Reverse layout, input border, preview window right 60%, wrap
   • Delimiter: whitespace 2+; select nth 1 for tag
   • Preview command:

     GH_FORCE_TTY=1 gh release view --repo OWNER/REPO {1}

   • Binds:
     • enter: execute gh release view --repo OWNER/REPO {1}
     • ctrl-o: execute-silent gh release view --repo OWNER/REPO {1} --web + abort
     • ctrl-p: toggle-preview
6. Nice-to-haves:
   • If body is long, allow --pager to pipe to less -R.
   • If glow exists, prefer:

     gh release view --json body | jq -r .body | glow -p

   • If both CHANGELOG and Releases exist, allow toggling via a flag or prompt hint.

Error handling and messages

• Early dependency checks with clear guidance if missing (brew install gh fzf jq glow).
• Helpful errors if repo resolution fails or not GitHub-hosted.
• Non-zero exit codes on hard failures.

File header skeleton (to match your helpers)

• Shebang, set -o flags
• A usage() function that prints flags and examples
• A die() helper for error messages
• main() function pattern and minimal globals
• Comments grouping: deps / parse / resolve / mode / fzf-ui

Examples

• Browse releases for a Homebrew formula:

  <script> -f brew -a 4.6.9

• Browse releases for a repo:

  <script> -r Homebrew/brew

• Open in browser by default:

  <script> -r OWNER/REPO --web

• Directly view CHANGELOG (if present):

  <script> -r OWNER/REPO --mode changelog

Optional future enhancement

• Integrate with brew outdated: pipe formulas through this helper with a small wrapper to select a formula first, then jump into its releases/changelog.