Git on ¬ just serendipity 🍀

myrepos: a wip action to find unfinished work

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 17 Jul 2026 12:23:10 +0200

Problem statement: I manage a few dozen repos via myrepos (mr), and I wanted a single command to show which ones have work in progress (“WIP”) — uncommitted changes, dirty staging area, stray branches and alike.

I want essentially a filtered version of mr ls.

So I defined my own command. A repo is not WIP when all three hold:

the default branch is checked out;
no other local branches exist;
and the working tree is fully clean.

Anything else gets flagged with a reason.

The definition:

# List repos with work in progress: not on default branch, extra local branches, or dirty tree.
# Run as `mr -m wip`: the -m (minimal) flag drops mr's per-repo "mr wip:" header and blank
# lines, leaving only the flagged repos. This cannot be defaulted per-action (mr only honors
# -m/-q as CLI flags, not via config).
wip =
 reasons=""
 cur=$(git symbolic-ref --quiet --short HEAD 2>/dev/null || echo "(detached)")
 def=$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')
 if [ -z "$def" ]; then if git show-ref --verify --quiet refs/heads/main; then def=main; elif git show-ref --verify --quiet refs/heads/master; then def=master; fi; fi
 if [ -n "$def" ] && [ "$cur" != "$def" ]; then reasons="$reasons branch:$cur"; fi
 n=$(git for-each-ref --format='%(refname)' refs/heads | wc -l | tr -d ' ')
 if [ "$n" -gt 1 ]; then reasons="$reasons +$((n-1))_branches"; fi
 if [ -n "$(git status --porcelain)" ]; then reasons="$reasons dirty"; fi
 if [ -n "$reasons" ]; then printf '%s [%s]\n' "$MR_REPO" "${reasons# }"; fi

Naturally, the snippet above is art from the LLM, but it accomplishes exactly what I want:

thiago.perrotta ~
% mr -m wip
mr wip: /Users/thiago.perrotta/Corp/gitops
/Users/thiago.perrotta/Corp/gitops [branch:thiagowfx/acme +1_branches]

mr wip: /Users/thiago.perrotta/Corp/terraform
/Users/thiago.perrotta/Corp/terraform [+1_branches]

mr wip: /Users/thiago.perrotta/workspace/perrotta.dev
/Users/thiago.perrotta/workspace/perrotta.dev [+3_branches dirty]

Clean repos stay silent. I get to see all repos with unfinished work, and I can see exactly why each one is dirty.

mr wip works too but it’s noisier. I need to add mr -m wip to my muscle memory¹. Without the -m flag, mr prepends a mr wip: header and a blank line for every repo, WIP or not.

-m can’t be baked into the action definition — mr only honors it as a CLI flag — so the comment above the action documents it.

Previously I’d run mr xl (an alias for git branch -vv across every repo) and eyeball the result — but that’s dozens of lines of branch tips for tens of repos, and I still have to scan for the ones that are actually behind or dirty. wip does the scanning: it only prints the repos that need attention, with the reason attached. Much more ergonomic than visually diffing a wall of green.

Runs read-only, so it’s safe to run twice.

🤖 Drafted with /bloggify.

Should I rely on this workflow more often, I could leverage Espanso or a shell alias/function to easen its recall. ↩︎

— § —

Reply via email

#coding #dev #git

pre-commit: authentication in internal github repos

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 18 Jun 2026 14:42:26 +0200

♠ Problem statement: prek can’t clone a repo: that lives in an internal (private) GitHub repo — https:// clone fails without credentials.

I forked my personal pre-commit-hooks into an org-owned repo and updated all our .pre-commit-config.yaml files to point at it:

- repo: https://github.com/<org>/pre-commit-hooks
  rev: 5695e23285bef67d1dee957e5c12e86f58ba843b # frozen: v1.0.0
  hooks:
    - id: check-bash-shebang

This approach works locally (my GitHub token is broad).

CI (github actions) fails though:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

The repo is INTERNAL, not public. As such, prek clones the repo: URL to fetch the hooks; with no credentials on the runner, it can’t.

First instinct: git@github.com:<org>/pre-commit-hooks. Runners have no SSH key though!

The fix is to keep https:// in the config, mint a short-lived token that can read the hooks repo, and tell git to rewrite the URL:

- name: Generate app token
  uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
  id: generate-token
  with:
    client-id: ${{ vars.APP_CLIENT_ID }}
    private-key: ${{ secrets.APP_PRIVATE_KEY }}
    owner: ${{ github.repository_owner }}
    repositories: pre-commit-hooks
    permission-contents: read
- uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
  with:
    persist-credentials: false
- name: Authenticate git for internal hook repos
  env:
    TOKEN: ${{ steps.generate-token.outputs.token }}
  run: git config --global url."https://x-access-token:${TOKEN}@github.com/".insteadOf "https://github.com/"
- uses: j178/prek-action@bdca6f102f98e2b4c7029491a53dfd366469e33d # v2.0.4

Two things worth noting.

First: never inline ${{ steps.generate-token.outputs.token }} directly into a run: shell string — zizmor (a GitHub Actions security linter) flags it as a template injection risk. Pass it via env: and use the shell variable instead.
Second: the repositories: pre-commit-hooks scope only works if the App is actually installed on that repo. That one is a manual step in GitHub’s UI — github.com/organizations/<org>/settings/installations → the App → Repository access → add the repo. No amount of YAML fixes it otherwise; it silently returns a 404 from the App installation endpoint otherwise.

After the installation grant, the clone goes through and prek runs cleanly.

🤖 Drafted with /bloggify.

— § —

Reply via email

#dev #git #pre-commit

git: switch-to-default with wt

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 14 Jun 2026 20:03:03 +0200

♠ My switch-to-default git alias had been trying branch names in order:

switch-to-default = !git switch --force main 2>/dev/null \
    || git switch --force master 2>/dev/null \
    || git switch --force $(git symbolic-ref refs/remotes/origin/HEAD \
        | sed 's@^refs/remotes/origin/@@')

It works, but it’s trial-and-error. Different people and different projects cannot decide whether to use main or master. It’s a mess.

Worktrunk tracks the default branch as part of its worktree state:

% wt config state default-branch
master

No need to guess!

New alias:

switch-to-default = !git switch --force \
    $(wt config state default-branch 2>/dev/null \
        || git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \
            | sed 's@^refs/remotes/origin/@@' \
        || echo master)

wt first, then fall back to origin/HEAD if wt is not installed, then master as a last resort.

🤖 Drafted with /bloggify.

— § —

Reply via email

#dev #git

★ Worktrunk

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 25 May 2026 10:57:00 +0200

♠ Worktrunk:

Git worktree management for parallel AI agent workflows

I stumbled upon worktrunk (wt) due to a fortunate coincidence, serendipity at its best. I was pitching my own pancake wt to someone, and this person asked if I hadn’t heard of worktrunk.

If you look at its git star history¹, you’ll notice that it became popular only at the beginning of 2026, whereas I wrote my wt back in November 2025. I did proper diligence at the time but couldn’t find anything resembling my vision. Normally I prefer to reuse rather than writing from scratch.

“AI agent workflows” is a tagline that does not convince me. If anything, it actually worsens my appeal to try out the software. Seriously. Riding the wave is not helpful.

What really sold me was its usage examples. I was able to immediately tell that it had very similar goals to my own wt (sans AI).

Setup #

First, install worktrunk:

brew install worktrunk

It is as simple (and rusty!) as it could be:

% brew ls worktrunk
/opt/homebrew/Cellar/worktrunk/0.53.0/.crates.toml
/opt/homebrew/Cellar/worktrunk/0.53.0/.crates2.json
/opt/homebrew/Cellar/worktrunk/0.53.0/bin/wt
/opt/homebrew/Cellar/worktrunk/0.53.0/etc/bash_completion.d/wt
/opt/homebrew/Cellar/worktrunk/0.53.0/sbom.spdx.json
/opt/homebrew/Cellar/worktrunk/0.53.0/share/fish/vendor_completions.d/wt.fish
/opt/homebrew/Cellar/worktrunk/0.53.0/share/zsh/site-functions/_wt

Shell completion is a bonus that you’ll definitely want, as noted in a previous post:

# worktrunk: https://worktrunk.dev/
(( $+commands[wt] )) && eval "$(wt config shell init zsh)"

The snippet above integrates well with my own dotfiles; a vanilla setup that most people should follow is, instead, wt config shell install, which will populate your .bashrc / .zshrc accordingly with wt config shell init.

The shell integration alone makes it compelling enough to switch to wt, but we’re not done yet.

Workflow #

It is possible to customize wt. I value muscle memory and the ability to easily recall commands, therefore I crafted this basic configuration to facilitate the migration from my own wt:

worktree-path = "{{ repo_path }}/.worktrees/{{ branch | sanitize }}"

[aliases]
add = "wt switch --create {{ args }}"
bd = "wt remove -D {{ args }}"
cd = "wt switch {{ args }}"
checkout = "wt switch {{ args }}"
cleanup = "wt step prune {{ args }}"
co = "wt switch {{ args }}"
commit = "wt step commit {{ args }}"
create = "wt switch --create {{ args }}"
del = "wt remove {{ args }}"
delete = "wt remove {{ args }}"
goto = "wt switch --no-cd {{ args }}"
ls = "wt list {{ args }}"
new = "wt switch --create {{ args }}"
prune = "wt step prune {{ args }}"
rm = "wt remove {{ args }}"
tui = "wt switch {{ args }}"
world = "wt step prune {{ args }}"
xl = "wt list {{ args }}"

[pre-start]
prek = "test -f .pre-commit-config.yaml && prek install --install-hooks || true"

[pre-merge]
prek = "test -f .pre-commit-config.yaml && prek run --from-ref \"$(git symbolic-ref --short refs/remotes/origin/HEAD)\" --to-ref HEAD || true"

You can start by running wt config create and then iterating upon the newly generated config file, which is very well documented. What a great developer experience!

Let’s break it down.

We start with wt add <feature> (upstream: wt switch --create). This will create a worktree:

tperrotta ~/Workspace/perrotta.dev git:master!?
% wt add myfeature
◎ Running pre-start user:prek
  test -f .pre-commit-config.yaml && prek install --install-hooks || true
prek installed at `/Users/tperrotta/Workspace/perrotta.dev/.git/hooks/pre-commit`
✓ Created branch myfeature from master and worktree @ ~/Workspace/perrotta.dev/.worktrees/myfeature
  39.06s user 6.26s system 251% cpu 17.984 total

tperrotta ~/Workspace/perrotta.dev/.worktrees/myfeature git:myfeature ⎇ myfeature
% git st
## myfeature...master

At any time, we can check the current status with wt xl (upstream: wt list):

tperrotta ~/Workspace/perrotta.dev/.worktrees/myfeature git:myfeature ⎇ myfeature
% wt xl
  Branch     Status        HEAD±    main↕  Remote⇅  Path                    Commit    Age   Message
@ myfeature      _                                  ./.worktrees/myfeature  23df7c41  50m   name author explicitly
^ master      !? ^|      +5   -6              |     .                       23df7c41  50m   name author explicitly

○ Showing 2 worktrees, 1 with changes

When opening a new shell, we can easily switch to the newly created worktree from the repo root with wt cd (upstream: wt switch):

tperrotta ~/Workspace/perrotta.dev git:master!?
% wt cd myfeature
○ Switched to worktree for myfeature @ ~/Workspace/perrotta.dev/.worktrees/myfeature

tperrotta ~/Workspace/perrotta.dev/.worktrees/myfeature git:myfeature ⎇ myfeature
%

Once we are done (e.g. created/merged a pull request), we can delete the worktree with wt bd or wt del (upstream: wt remove -D).

That’s all! The core workflow steps are quite easy to assimilate.

You’ll notice that my worktrees are created in a .worktrees directory within the git repository root. This is due to my setting worktree-path in the config file. The default behavior of worktrunk is to use sibling directories (e.g. ../myrepo.myfeature from the git root).

As you can see from my config file, I have also integrated prek (pre-commit) to it:

the creation of a worktree yields prek install
the merge of a worktree (not covered in this post) yields prek run on the affected commits

wt has many other features; this is just the tip of the iceberg.

GitHub stars are a vanity metric but they are occasionally useful. ↩︎

— § —

Reply via email

#ai #bestof #dev #git #pkm #pre-commit

wt: exec shell vs shell integration

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 21 May 2026 17:02:29 +0200

♠ Previously.

Problem statement: my wt tool’s cd subcommand does not survive a terminal split — the new pane opens at the original directory, not the worktree. worktrunk’s wt does(!)

A subprocess cannot change its parent’s working directory (PWD). wt.sh works around it by replacing the script process with a fresh shell:

cd "$target_path" || exit 1
exec "$SHELL"

The exec "$SHELL" is the culprit. The interactive shell process is gone, replaced by a new one rooted in the worktree. The terminal emulator’s record of “what shell is (currently) running in this pane” still points to the original PID’s cwd at split time — not the new shell’s. Shell history, env vars, pushd/popd stack, prompt state: all lost too (not that I particularly care about all these).

worktrunk ships a shell integration step:

% wt config shell install

That installs a function in ~/.bashrc / ~/.zshrc (or equivalent for other shells) which evals the binary’s output in the current shell. The cd happens in the shell we are actually using. No exec, no replacement, no lost state. Splits inherit the real, updated cwd.

The README of my wt already documents the escape hatch:

% cd "$(wt goto feature-x)"

…which is the same trick, just manual. The goto subcommand prints the path; cd runs in the shell.

The proper fix is to ship a wt shell init that emits an eval-able function, and route cd/bd/add through it. I do not plan to do so though, wt is not supposed to become a complex project. In fact, perhaps it will even be deprecated, should I end up switching to worktrunk.

— § —

Reply via email

#dev #git

★ Small PRs

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 18 May 2026 11:48:14 +0200

♠ From the Google Engineering Practices handbook:

Why Write Small CLs?

Reviewed more quickly

Reviewed more thoroughly

Less likely to introduce bugs

Less wasted work if they are rejected

Easier to merge

Easier to design well

Less blocking on reviews

Simpler to roll back

CLs = ChangeLists = PRs = Pull Requests

Full documentation.

My additions:

Easier to test
Easier to explain to a teammate
Easier for LLMs to ingest

— § —

Reply via email

#bestof #dev #git #serenity

★ GitHub: review only files owned by you

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 28 Apr 2026 11:01:10 +0200

♠ If you use CODEOWNERS on GitHub, there is a neat¹ feature to streamline your pull request reviews.

Arguably, in large codebases, you’re only interested in reviewing files owned by you or your team. Wouldn’t it be great if you could filter out files that you do not own?

This turns out to be possible.

Workflow:

go to a given pull request
click “Files changed” in the top navbar (it’s the last tab)
on the left sidebar, click the filter button
click “Only files owned by you”

Boom. The file noise is gone now!

In case you can’t easily spot the filter button, take a look at the screenshot in the link above.

Neat and hard to discover! ↩︎

— § —

Reply via email

#bestof #dev #git

git: empty stash

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 09 Apr 2026 12:48:57 +0200

♠ There are too many entries in my git stash:

% git stash list | wc -l
69

I would like to completely empty it, nothing there matters, it’s all draft junk accumulated over months.

% git stash clear

Verification:

% git stash list | wc -l
0

That’s all! It’s the first time I ran this command.

Normally I do this instead:

% git stash drop

drop

Remove a single stash entry from the list of stash entries.

In zsh land, if I hadn’t learned about stash clear, I could have done the following instead:

% repeat 100 git stash drop

…popping each entry one by one.

— § —

Reply via email

#dev #git

pre-commit: periodic garbage collection

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 07 Apr 2026 10:56:21 +0200

♠ How funny, I do not remember setting this up. It is useful nonetheless:

thiago.perrotta ~
❯ crontab -l
30 12 1-7 * 5 [ "$(( ($(date +\%-d)-1)/7+1 ))" -eq 1 ] && /opt/homebrew/bin/pre-commit gc >> /Users/thiago.perrotta/.cronlogs/pre-commit-gc.log 2>&1

thiago.perrotta ~
❯ cat /Users/thiago.perrotta/.cronlogs/pre-commit-gc.log
2 repo(s) removed.
0 repo(s) removed.
3 repo(s) removed.
20 repo(s) removed.
10 repo(s) removed.
18 repo(s) removed.
2 repo(s) removed.
0 repo(s) removed.
0 repo(s) removed.
4 repo(s) removed.
61 repo(s) removed.
5 repo(s) removed.
0 repo(s) removed.
0 repo(s) removed.
0 repo(s) removed.
1 repo(s) removed.
26 repo(s) removed.
17 repo(s) removed.
9 repo(s) removed.
11 repo(s) removed.
1 repo(s) removed.
3 repo(s) removed.
10 repo(s) removed.
1 repo(s) removed.
6 repo(s) removed.
1 repo(s) removed.
6 repo(s) removed.
4 repo(s) removed.
0 repo(s) removed.
15 repo(s) removed.
0 repo(s) removed.
2 repo(s) removed.
4 repo(s) removed.
1 repo(s) removed.
16 repo(s) removed.
0 repo(s) removed.
0 repo(s) removed.
0 repo(s) removed.
0 repo(s) removed.
0 repo(s) removed.
0 repo(s) removed.

What does gc do? As per the docs:

Clean unused cached repos.

pre-commit keeps a cache of installed hook repositories which grows over time. This command can be run periodically to clean out unused repos from the cache directory.

This is on macOS. If I were on Linux, I’d prefer systemd timers instead.

Previously.

— § —

Reply via email

#dev #git #pre-commit

★ pancake workflow (OR: how to solve problems only once)

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 06 Apr 2026 11:52:10 +0100

♠ Previously.

Software Engineers / Programmers and the like have had curated dotfiles for ages.

These days (2025s), we’re evolving to times where it makes sense to curate collections of other utilities as well:

pancake is my own little repo for all sorts of CLI utilities. Its first commit was on Sep 25th, 2025, and now it’s a core part of my workflow, which is what this post will dive into.

First of all, obligatory xkcd:

XKCD Courtesy of Randall Munroe

It became really, really cheap (in terms of time) to automate all sorts of tasks with the advent of better coding agents last year. And this totally changes the game.

Workflow #

I have a problem. An issue. A task. Let’s exemplify with today’s¹ issue:

Problem statement: given a local git repository with various branches, create a worktree for each of them.

Step 1: go to the pancake repo.

% z pancake

Step 2: prompt the LLM.

❯ create a new script called "wt" (short for worktree).
  Given a local git repo, it should create a worktree for each
  remote branch. Use the same conventions as the other scripts
  in this repo (help2man compatible, -h/--help, etc).

Claude Code reads the existing scripts, matches the conventions, and writes the new one. I review it, maybe nudging it once or twice.

Step 3: commit, push, release.

% git add wt/
% git commit -a -m "new script: wt"
% git push
% just release

just release creates a CalVer tag (e.g. 2026.01.27.0), pushes it, and GitHub Actions updates the Homebrew formula automatically.

Step 4: install it.

% just update

This is a wrapper around brew upgrade thiagowfx/pancake/pancake.

Step 5: use it.

% cd ~/Workspace/some-repo
% wt

That’s it. Problem solved, script in the toolbox, reusable forever.

The whole cycle — from “I wish I had a tool for this” to “it’s installed and working” — takes O(minutes). The LLM does virtually everything: writes the script, follows the repo conventions, generates help text. I just steer and review.

Before coding agents, I’d weigh whether it was worth the O(hours) to write a proper script with argument parsing, help text, cross-platform support. Most of the time the answer was “no”, and I’d settle for a brittle alias or just remember the command. Now the answer is almost always “yes”.

The xkcd chart above needs to be recalibrated. The “time to automate” column collapsed by an order of magnitude, so long as you’re willing to burn LLM tokens.

As of this writing, pancake has 30+ scripts.

Some highlights:

retry — retry a command until it succeeds, with timeouts and output diffing (inspired by zsh)
murder — graceful process killing with signal escalation (TERM → INT → HUP → KILL) (one step above pkill)
notify — cross-platform desktop notifications (inspired by notify-send)
timer — countdown timer with notification when done
wt — the worktree script from today

Each one started the same way: a problem, a prompt, a review, a release.

The repo name is silly but the idea is practical: solve problems once. Every time I catch myself running a multi-step command more than twice or thrice, it becomes a pancake script. The cost of doing so used to be high enough that I’d only bother for frequent tasks. Now it’s so low that even a task I’ll run twice a year gets a script, so long as it’s reusable and comprensive enough.

In 2026, the compounding effect from curating your own toolbox does pay off.

This post has been originally drafted in January 2026, but it was only finished in April 2026. ↩︎

— § —

Reply via email

#ai #bestof #dev #git

★ mr update

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 26 Mar 2026 16:36:56 +0100

♠ Every day at the office, I start my day with mr update:

% mr update
[...]
mr update: /Users/thiago.perrotta/workspace/adventofcode
Already up to date.

mr update: /Users/thiago.perrotta/workspace/check-json-schema-meta
Already up to date.

mr update: /Users/thiago.perrotta/workspace/homebrew-taps
Already up to date.

mr update: /Users/thiago.perrotta/workspace/pre-commit-hooks
Already up to date.

mr update: /Users/thiago.perrotta/workspace/pancake
Already up to date.
[...]

mr is short for myrepos:

You have a lot of version control repositories. Sometimes you want to update them all at once. Or push out all your local changes. You use special command lines in some repositories to implement specific workflows. Myrepos provides a mr command, which is a tool to manage all your version control repositories.

mr is a single tool to control multiple DVCSes at once — typically git, but others are also supported:

All you need to get started is some already checked out repos. These could be using git, or bzr, mercurial or darcs, or many other version control systems. Doesn’t matter, they’re all supported!

The example output above was lame because nothing changed — they’re my personal repositories. In the git repositories of my workplace there are typically various changes to be absorbed every day.

How do we achieve this?

Refer to its man page for the config format. My config:

# vim: ft=conf

include = cat ~/.mrconfig.defaults

[.dotfiles]
checkout = git clone 'git@github.com:thiagowfx/.dotfiles.git' '.dotfiles'

[.dotfiles_corp]
checkout = git clone 'git@github.com:thiagowfx/.dotfiles_corp.git' '.dotfiles_corp'
skip = lazy

[workspace/adventofcode]
checkout = git clone 'git@github.com:thiagowfx/adventofcode' 'adventofcode'
skip = lazy

[workspace/check-json-schema-meta]
checkout = git clone 'git@github.com:thiagowfx/check-json-schema-meta' 'check-json-schema-meta'
skip = lazy

[workspace/aports]
checkout = git clone 'git@gitlab.alpinelinux.org:thiagowfx/aports.git' 'aports'
skip = lazy
update = git pull upstream master

[workspace/homebrew-taps]
checkout = git clone 'git@github.com:thiagowfx/homebrew-taps' 'homebrew-taps'
skip = lazy

[workspace/pancake]
checkout = git clone 'git@github.com:thiagowfx/pancake' 'pancake'
skip = lazy

[workspace/perrotta.dev]
checkout = git clone 'git@github.com:thiagowfx/thiagowfx.github.io.git' 'perrotta.dev'
skip = lazy

[workspace/pre-commit-hooks]
checkout = git clone 'git@github.com:thiagowfx/pre-commit-hooks' 'pre-commit-hooks'
skip = lazy

# vim: ft=conf

[ALIAS]
pull = update

[DEFAULT]
git_xl = git xl "$@"
jobs = 6

— § —

Reply via email

#bestof #dev #git

Github Status

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 10 Mar 2026 23:56:52 +0100

♠ Github has a status page: https://www.githubstatus.com/

“The Missing GitHub Status Page” goes deeper (via Kottke): https://mrshu.github.io/github-statuses/

Last 90 days uptime

Last updated Mar 9, 2026

81 incidents in last 90 days

GitHub Platform

91.62% uptime

Ouch. So much for HA and the five nines. Can’t even reach two…

— § —

Reply via email

#dev #git #selfhosted

ee: exit all shells

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 23 Feb 2026 11:52:17 +0100

♠ Problem statement: I present this to you the same way I presented it to Amp Code in the context of my ~/.dotfiles:

new shell alias: ee

quit all shells

example:

$ bash
$ bash
$ zsh

Now we're 3 levels deep.
"ee" should quit them all (effectively closing the underlying terminal emulator tab)

Why do I even have this issue in the first place? Utilities like wt (to manage git worktrees) and try (to manage scratch directories) need to change directories. Alas, it’s not possible to change the current working directly ($PWD) with a script. As such, my workaround is to open a subshell in the desired directory. As a side effect, I end up with nested subshells.

Why ee? I close my shell with C-d (Ctrl + D). In this context I need to press it three times in a row. dd would have been a natural alias but I’d rather avoid the name clash with the dd disk cloning util. ee came next naturally.

This version works in bash but not in zsh:

% which ee
ee () {
        pid=$$
        pids=$pid
        while ppid=$(ps -o ppid= -p "$pid" | tr -d ' ')  && [ "$ppid" -gt 1 ] 2> /dev/null
        do
                case "$(ps -o comm= -p "$ppid" 2>/dev/null)" in
                        (*sh) pids="$pids $ppid"
                                pid=$ppid  ;;
                        (*) break ;;
                esac
        done
        kill -HUP $pids
}

The issue is zsh doesn’t word-split unquoted variables like bash/sh does. $pids is passed as a single string. Fix with eval:

The version below works in both bash and zsh:

ee () {
        pid=$$
        pids=$pid
        while ppid=$(ps -o ppid= -p "$pid" | tr -d ' ')  && [ "$ppid" -gt 1 ] 2> /dev/null
        do
                case "$(ps -o comm= -p "$ppid" 2>/dev/null)" in
                        (*sh) pids="$pids $ppid"
                                pid=$ppid  ;;
                        (*) break ;;
                esac
        done
        eval "kill -HUP $pids"
}

The only difference is the last line:

-       kill -HUP $pids
+       eval "kill -HUP $pids"

The resulting solution is a shell function, not an alias, but that’s perfectly acceptable.

— § —

Reply via email

#dev #git

github workflow: external script

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 22 Feb 2026 14:10:11 +0100

♠ Problem statement: execute a .js script in a GitHub workflow. The script must be stored in a separate file (than the workflow) in the same git repository.

Why store the file separately?

Inlining a big script is ugly and very non-elegant
No syntax highlighting when updating the script → error-prone
Risk of messing up with string interpolation or escaping characters → error-prone
Limited ability to use formatters and linters in inlined scripts

The following approach, taken from a real example, works well:

% tree {repo root}/.github/
.github/
├── scripts
│   └── drift-summary.js
└── workflows
    ├── drift-summary.yml
    [...]

name: 'Drift Summary'

on:
  schedule:
    - cron: '0 9 * * MON-FRI'
  workflow_dispatch:

permissions:
  issues: write

jobs:
  summarize:
    name: 'Update drift summary issue'
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@1af3b93b6815bc44a9784bd300feb67ff0d1eeb3 # v6.0.0
        with:
          persist-credentials: false

      - name: 'Aggregate drift and update summary'
        uses: actions/github-script@f28e40c7f34bde8b3046d885e986cb6290c5673b # v7
        with:
          script: |
            const script = require('./.github/scripts/drift-summary.js');
            await script({ github, context });

Use github-script + require.

— § —

Reply via email

#dev #git #pre-commit

GitHub: approve PRs from CLI

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 04 Feb 2026 11:10:58 +0100

♠ Problem statement: approve a given github pull request from the CLI.

Why?

Presumably you would do the PR review outside the GitHub web UI (it’s slow, eh?). How to do this is out of scope of this post.

Let’s assume the review is done, and all that is left is to approve the PR.

Let’s also assume you have a local checkout of the repository, and your CWD is set to it.

First, check the PR out:

thiago.perrotta ~/Corp/terraform git:main
% gh co
? Select a pull request  [Use arrows to move, type to filter]
> 509   OPEN Change ai-resources repository visibility to internal [fix/ai-resources-visibility-internal]
[...]

Now approve it:

thiago.perrotta ~/Corp/terraform git:fix/ai-resources-visibility-internal? #509
% gh pr review --approve
✓ Approved pull request corp/terraform#509

It’s possible to approve the PR without checking it out:

% gh pr review -h
Add a review to a pull request.

Without an argument, the pull request that belongs to the current branch is reviewed.


USAGE
  gh pr review [<number> | <url> | <branch>] [flags]

% gh pr review 509 --approve

— § —

Reply via email

#dev #git

starship: github PR prompt

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 30 Jan 2026 00:51:51 +0100

♠ Previously.

Problem statement: add to starship the GitHub PR associated with the current git branch.

The following starship custom module does the trick:

[custom.github_pr]
command = "bkt --ttl=10m --scope=\"$(git rev-parse --show-toplevel):$(git branch --show-current)\" -- gh pr view --json number --jq '\"#\" + (.number | tostring)' 2>/dev/null"
when = "git rev-parse --is-inside-work-tree 2>/dev/null"
format = " [$output](magenta)"
ignore_timeout = true

The module is activated only within git repositories (see the when variable).

The command consists of the gh CLI, as you would expect. There’s one major problem: it makes a network call on every prompt. This is super inefficient. Can’t do.

That’s why we use bkt: it caches the PR info for a certain amount of time (10 minutes in the aforementioned example), which makes this a feasible prompt.

The full prompt (without colors) looks roughly like this:

thiago.perrotta ~/.dotfiles git:master! ⎇ #466
❯

The full git commit that implements and uses it:

% git --no-pager show
commit d2a80f6b8edfa6a07204a1d97b278abacba57813 (HEAD -> master)
Author: Thiago Perrotta <{redacted}>
Date:   Fri Jan 30 00:55:02 2026 +0100

    starship: add github pr

diff --git starship/.config/starship.toml starship/.config/starship.toml
index 2c5e78e..9fbf19b 100644
--- starship/.config/starship.toml
+++ starship/.config/starship.toml
@@ -1,5 +1,5 @@
 # Minimal starship config matching grml prompt
-format = "$status$sudo$username$hostname$directory$git_branch$git_state$git_status${custom.git_worktree}$line_break$character"
+format = "$status$sudo$username$hostname$directory$git_branch$git_state$git_status${custom.git_worktree}${custom.github_pr}$line_break$character"
 right_format = "$cmd_duration$jobs"
 add_newline = true

@@ -52,3 +52,9 @@ command = "printf '⎇'"
 when = "[ -f .git ]"
 format = " [$output]($style)"
 style = "bold yellow"
+
+[custom.github_pr]
+command = "bkt --ttl=10m --scope=\"$(git rev-parse --show-toplevel):$(git branch --show-current)\" -- gh pr view --json number --jq '\"#\" + (.number | tostring)' 2>/dev/null"
+when = "git rev-parse --is-inside-work-tree 2>/dev/null"
+format = " [$output](magenta)"
+ignore_timeout = true

— § —

Reply via email

#dev #git

git aicommit

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 13 Jan 2026 15:58:48 -0300

♠ Problem statement: auto-generate a commit message for git from the command-line. The solution should be vendor agnostic.

Given a git-foo.sh in $PATH, it can be invoked as git foo, as if it were a built-in git command.

This is helpful to enable seamless integration with git. I chose to call the subcommand aicommit. I suppose commit-ai would also be sensible.

The goal is to create git-aicommit.sh in ~/.bin (which is in my $PATH via my .dotfiles)

This initial draft worked well:

#!/bin/bash
#
# git-aicommit - Create a commit with an AI-generated title based on staged changes

set -e

# Check if we're inside a git repository
if [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" != "true" ]; then
  echo "Error: Not in a git repository"
  exit 1
fi

# Check if there are staged changes
if git diff --cached --quiet; then
  echo "Error: No staged changes to commit"
  exit 1
fi

# Select AI agent (default: claude)
agent="${GIT_AI_AGENT:-claude}"
case "$agent" in
  # keep-sorted start
  amp|ampcode)
    ai_prompt() { amp -x "$1"; }
    ;;
  claude)
    ai_prompt() { claude -p "$1"; }
    ;;
  # keep-sorted end
  *)
    echo "Error: Unknown AI agent: $agent"
    exit 1
    ;;
esac

prompt="Look at the staged git changes and create a summarizing git commit title. Only respond with the title and no affirmation."

# Generate commit message and commit
echo "Generating commit message with $agent..."
git commit -m "$(ai_prompt "$prompt")" "$@"

echo "AI commit created successfully"

Refer to this source for an up-to-date version as it evolves.

Let’s break it down:

Previously: we employ an oneshot command to call an LLM agent, so that there’s no need to do it interactively. Initially I added only Claude Code and Amp because they are the agents I use the most; perhaps this list will be expanded later on but it is not intended to be exhaustive¹.
The command is intended to run in O(seconds). If it takes too long, then it should be simplified (via a better prompt).
By default it uses Claude. To use another agent, call it like:

GIT_AI_AGENT="amp" git aicommit

This preference could be trivially made persistent on a per-repo basis by using direnv. For example, use Claude at work and Amp in personal git repositories².

Later on I split the command into two: git aicommit and git aicommit-quick. “Quick” populates the commit message title only (think git commit -m "foo"), whereas the non-quick version populates the body as well, accounting for GitHub PR templates when they exist. Time will tell whether I need this distinction.

This gives me the idea to create a separate script for “oneshotting” LLMs in pancake. ↩︎
It’s all Claude anyway, this distinction is mostly for the sake of discretionary billing. ↩︎

— § —

Reply via email

#ai #dev #git

new script: uwatch

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 10 Jan 2026 22:39:53 -0300

♠ Problem statement: watch -- git diff / watch -- git status should emit colors. Yet it doesn’t.

watch(1):

NAME

watch - execute a program periodically, showing output fullscreen

SYNOPSIS

watch [option ...] command

DESCRIPTION

watch runs command repeatedly, displaying its output and errors (the first screenful). This allows you to watch the program output change over time. By default, command is run every 2 seconds and watch will run until interrupted. A header informs of the start and running time of command as well as its exit code.

You typically address this with watch -c:

-c, --color
  Interpret ANSI color and style sequences.

And yet, watch -c -- git status still won’t emit colors. This is because git “knows” the output is going through a TTY (watch), and thus defensively disables colors. Some programs control this behavior with a --color=always switch (the default is typically auto).

Without diving deep into what’s happening underneath (terminal ANSI escape colors, TTY output detection), the magical solution is to use unbuffer(1), which was previously covered. unbuffer is agnostic of the underlying program; it doesn’t matter whether it uses --color, or CLICOLOR, or another mechanism.

Thus we achieve this form:

% watch -c -- unbuffer git status

But it’s super tedious to remember and to type out the -c -- unbuffer bits.

To resolve this, I created a wrapper: uwatch(1). The u alludes to “unbuffer”:

Run a command repeatedly using watch, preserving colored output.

Uses unbuffer to maintain color codes through watch's output. Useful for monitoring git status, test output, or any command with color formatting.

Usage:

uwatch [--] git status

The -- separator is optional.

— § —

Reply via email

#dev #git

git: shell prompt: worktrees

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 10 Jan 2026 15:15:21 -0300

♠ My shell prompt displays the git branch my repository has currently checked out:

thiago.perrotta perrotta.dev git:master?
❯

Problem statement: augment that prompt to signal whether we’re inside a checked out git worktree.

This is helpful because lately multiple repository worktrees have been popularized thanks to LLM coding agents.

The following change to starship does the trick:

commit b7de6881c0fb57c840def52189502985442842e1
Author: Thiago Perrotta <{redacted}>
Date:   Fri Jan 9 21:18:09 2026 -0300

    starship: add worktree symbol

diff --git starship/.config/starship.toml starship/.config/starship.toml
index 87df9ff..ea7acc8 100644
--- starship/.config/starship.toml
+++ starship/.config/starship.toml
@@ -1,5 +1,5 @@
 # Minimal starship config matching grml prompt
-format = "$status$sudo$username$hostname$directory$git_branch$git_state$git_status$line_break$character"
+format = "$status$sudo$username$hostname$directory$git_branch$git_state$git_status${custom.git_worktree}$line_break$character"
 right_format = "$cmd_duration$jobs"
 add_newline = true

@@ -24,13 +24,13 @@ format = " [$path](bold) "

 [git_branch]
 symbol = "git:"
-format = "[$symbol$branch](bold cyan) "
+format = "[$symbol$branch](bold cyan)"

 [git_state]
 format = "|[$state]()"

 [git_status]
-format = "[$conflicted$deleted$renamed$modified$staged$untracked$ahead_behind](red) "
+format = "[$conflicted$deleted$renamed$modified$staged$untracked$ahead_behind](red)"

 [cmd_duration]
 min_time = 2000
@@ -46,3 +46,9 @@ format = "[🧙](red) "
 [character]
 success_symbol = "[❯](green)"
 error_symbol = "[x](red)"
+
+[custom.git_worktree]
+command = "printf '⎇'"  # or 🌲, but I find the emoji too distracting in this context
+when = "git rev-parse --is-inside-work-tree 2>/dev/null && [ -f $(git rev-parse --git-dir)/commondir ]"
+format = " [$output]($style)"
+style = "bold yellow"

You don’t need to use starship to adopt it. The core logic is:

git rev-parse --is-inside-work-tree &>/dev/null && [ -f "$(git rev-parse --git-dir)/commondir" ] && printf '⎇'

The result:

thiago.perrotta perrotta.dev git:thiagowfx/my-custom-branch ⎇
❯

It is subtle yet informative.

— § —

Reply via email

#ai #dev #git

git: diff untracked

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 04 Jan 2026 04:29:01 -0300

♠ Previously.

If we can stash untracked files (git stash -u), should we be able to git diff untracked files?

Naturally, diffing an untracked file would output the entire file contents. Still, this can be desirable sometimes.

When reviewing multiple files, some of which are modified, and some of which are brand new, you may want to review the entire list at once.

Let’s try it out:

% cdtmp
/var/folders/yr/6sw3yylx6gjcy5jr38d6j6000000gn/T/thiago.perrotta-2026-01-04-l8Co7f
% git init
Initialized empty Git repository in /private/var/folders/yr/6sw3yylx6gjcy5jr38d6j6000000gn/T/thiago.perrotta-2026-01-04-l8Co7f/.git/
% echo world > hello.md
% git status
## No commits yet on master
?? hello.md
% git diff
% git diff -u

Err, no luck. In fact, from git-diff(1):

-p, -u, –patch

Generate patch (see the section called “GENERATING PATCH TEXT WITH -P”). This is the default.

Ouch. That’s not the -u we’re looking for!

We can attempt a similar test with git add -p:

% cdtmp
/var/folders/yr/6sw3yylx6gjcy5jr38d6j6000000gn/T/thiago.perrotta-2026-01-04-l8Co7f
% git init
Initialized empty Git repository in /private/var/folders/yr/6sw3yylx6gjcy5jr38d6j6000000gn/T/thiago.perrotta-2026-01-04-l8Co7f/.git/
% echo world > hello.md
% git status
## No commits yet on master
?? hello.md
% git add -p
No changes.

No luck either.

Not all hope is lost though.

Enter git add -N (--intent-to-add):

> -N, --intent-to-add
>
> Record only the fact that the path will be added later. An entry for the
> path is placed in the index with no content. This is useful for, among other
> things, showing the unstaged content of such files with git diff and
> committing them with git commit -a.

If we do git add -N hello.md, the following happens:

% git add -N hello.md
% git --no-pager diff
diff --git hello.md hello.md
new file mode 100644
index 0000000..cc628cc
--- /dev/null
+++ hello.md
@@ -0,0 +1 @@
+world

Yes! There’s our diff. Now git add -p:

% git add -N hello.md
% git add -p
diff --git a/hello.md b/hello.md
new file mode 100644
index 0000000..cc628cc
--- /dev/null
+++ b/hello.md
@@ -0,0 +1 @@
+world
(1/1) Stage addition [y,n,q,a,d,e,p,P,?]?

It works too!

git reset --hard picks it up as well.

In order to make this workflow ergonomic, run git add -AN (-A = --all) prior to git diff or git add -p, so that all new files are accounted for.

★ neovim: inline git hunk control

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 03 Jan 2026 15:41:21 -0300

♠ What is a hunk?

When comparing two files, diff finds sequences of lines common to both files, interspersed with groups of differing lines called hunks¹.

There are various ways to treat git hunks as first-class citizens, manipulating them one at a time – staging, unstaging, or reverting them.

The classic one is git add [-p | --patch]. Hit yes or no for each hunk, one by one:

% git add -p
diff --git a/Justfile b/Justfile
index bbb3779a9..70840a008 100755
--- a/Justfile
+++ b/Justfile
@@ -175,3 +175,6 @@ update-pre-commit:
 # Update JSON schemas
 update-json-schemas:
     pre-commit run -a update-json-schemas --hook-stage manual
+
+hello:
+    echo world
(1/1) Stage this hunk [y,n,q,a,d,e,p,P,?]?

There’s also git add [-i | --interactive]:

% git add -i

*** Commands ***
  1: status       2: update       3: revert       4: add untracked
  5: patch        6: diff         7: quit         8: help
What now>

It’s also possible to manage hunks via git TUIs (=from the terminal) such as:

…or graphically with IDEs with as VSCode.

An honorable mention also goes to git-crecord, which I originally discovered by looking for an open source alternative to Google’s Fig² interactive commit and split commands.

Now that you see how my mind is overloaded with many possibilities to manipulate git hunks, the natural follow-up question is: how to do so right from within our favorite text editor (vim)?

With classic vim, Tim Pope’s vim-fugitive is often touted as best-in-class (paired with vim-gitgutter). I use it occasionally. The workflow is as follows:

From an open file with modifications, run :GDiff (:GDiffsplit).
Proceed as you normally would in vimdiff. Use :diffget (do) and :diffput (dp) for each hunk. Use [c and ]c to navigate to the previous / next hunk.

Finally, we get to the meat of the post. Is there any workflow improvement in neovim, which I have recently switched to?

First of all, the familiar vim-fugitive workflow still works there.

Its evolution is gitsigns.nvim:

Git integration for buffers

Given the config below, the following becomes possible:

-- Git integration
{
'lewis6991/gitsigns.nvim',
config = function()
  require('gitsigns').setup({
    on_attach = function(bufnr)
      local gs = require('gitsigns')
      -- ]c / [c: next/prev hunk (falls back to default in diff mode)
      -- like git-gutter in vim
      vim.keymap.set('n', ']c', function()
        if vim.wo.diff then return ']c' end
        vim.schedule(function() gs.nav_hunk('next') end)
        return '<Ignore>'
      end, { expr = true, buffer = bufnr, desc = 'Next hunk' })
      vim.keymap.set('n', '[c', function()
        if vim.wo.diff then return '[c' end
        vim.schedule(function() gs.nav_hunk('prev') end)
        return '<Ignore>'
      end, { expr = true, buffer = bufnr, desc = 'Prev hunk' })
      vim.keymap.set('n', '<leader>s', gs.stage_hunk, { buffer = bufnr, desc = 'Stage hunk' })
      vim.keymap.set('n', '<leader>u', gs.reset_hunk, { buffer = bufnr, desc = 'Reset hunk' })
    end,
  })
end,
},
'tpope/vim-fugitive',

Use ]c and [c to navigate hunks (compatible with vim-gitgutter)
Use <leader>s (comma + s in my setup) to toggle staging/unstaging hunks.
Use <leader>u to do the equivalent of git checkout -- file for a single hunk.

The last two shortcuts are wherein the magic lives.

It is VERY convenient to choose what to stage/unstage/revert right from the nvim buffer I am currently editing. For fine-grained control, I can always use :Gdiff to perform hunk microsurgery.

Not to confound with hook. ↩︎
Internal mercurial VCS porcelain on top of Piper / google3. ↩︎

— § —

Reply via email

#bestof #dev #git #vim

myrepos: chain configs

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 22 Dec 2025 14:45:45 -0300

♠ myrepos:

You have a lot of version control repositories. Sometimes you want to update them all at once. Or push out all your local changes. You use special command lines in some repositories to implement specific workflows. Myrepos provides a mr command, which is a tool to manage all your version control repositories.

I use mr to manage my local git checkouts, see my ~/.mrconfig.

From $HOME, running mr update keeps all managed repositories up-to-date (git fetch / git pull).

Problem statement: Extend (chain) my mrconfig with git repositories from work.

I keep my git repos from work in ~/Corp.

Changing directory to it and running mr update updates work repos only.

The goal is to have mr update in ~ perform updates for personal AND work repos. We can achieve this with configuration chaining.

This commit addresses it:

# chain corp repositories
include = test -f $HOME/Corp/.mrconfig && sed 's|^\[\([^/DEFAULT]\)|[Corp/\1|' $HOME/Corp/.mrconfig || true

Rationale: If ~/Corp/.mrconfig exists, include it in the original ~/.mrconfig. The sed expression is necessary to adjust relative paths when operating on work repos, so that they all stay within ~/Corp, otherwise they would be cloned in ~.

The test and || true is to make this inclusion optional, with graceful degradation in case the work .mrconfig does not exist, thereby simply skipping it.

— § —

Reply via email

#dev #git

★ git: stash untracked files

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 22 Dec 2025 02:30:06 -0300

♠ As I write this very post, this is what my git repository status looks like:

% git st
## master...origin/master
?? content/posts/2025-12-22-git-stash-untracked.md

What if I wanted to stash it?

% git stash
No local changes to save
% git st
## master...origin/master
?? content/posts/2025-12-22-git-stash-untracked.md

Nothing happens, because this post is a new file, not yet tracked by git.

The classic way to address this is to switch to another branch, commit everything (e.g. with git-freeze), and then switch back. But this is slow.

Today I learned about git stash -u:

-u, --include-untracked, --no-include-untracked
    When used with the push and save commands, all untracked files are               also stashed and then cleaned up with git clean.

    When used with the show command, show the untracked files in the
    stash entry as part of the diff.

Let’s try it:

% git stash -u
Saved working directory and index state WIP on master: 58cde6e88 hide codeblock header in RSS feeds
% git st
## master...origin/master

The new post gets stashed indeed!

I don’t know how I missed this feature – I’ve wanted this functionality for stash since forever!

— § —

Reply via email

#bestof #dev #git

★ git: prune stale branches

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 27 Nov 2025 18:04:45 -0300

♠ Problem statement: Delete all local git branches whose counterpart remote branches have already been merged upstream.

Update ~/.gitconfig:

[alias]
    prune-gone = !git fetch -p && git branch -vv | awk '/: gone]/{print $1}' | xargs -r git branch -D
    world = !git fetch --all && git remote prune origin && git prune && git prune-gone

Now simply run git prune-gone – or, even better, git world for a more complete cleanup.

This is much more ergonomic than hunting down individual branches and doing git push origin :{my branch}.

Example usage:

% ~/Workspace/pancake (git)-[master]
% git world
From github.com:thiagowfx/pancake
 - [deleted]         (none)     -> origin/thiagowfx/apkbuild-sync
 - [deleted]         (none)     -> origin/thiagowfx/wt-no-origin-graceful
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 8 (delta 5), reused 3 (delta 3), pack-reused 0 (from 0)
Unpacking objects: 100% (8/8), 2.61 KiB | 668.00 KiB/s, done.
   f727bd7..51f81ee  master     -> origin/master
Deleted branch thiagowfx/wt-cd-dash (was 6403261).

— § —

Reply via email

#bestof #dev #git

git stash -m

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 23 Nov 2025 13:14:09 -0300

♠ When running git stash, it’s possible to pass a “stash message” to it with -m, just like how you give a “commit message” to git commit.

git stash -m "first draft, approach #1 from design doc"

You can view past stashes with git stash list:

% git stash list
stash@{0}: On master: first draft, approach #1 from design doc
[...]

Now your ~~junk~~ stashes can be properly organized!

— § —

Reply via email

#dev #git

git diff interactively

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 04 Nov 2025 11:21:24 +0100

♠ It’s possible to do git patch -p to review diff hunks interactively, one by one.

Can we accomplish something similar with git diff? If not, is there a tool that can accomplish that, in the same spirit of git patch -p, but with a read-only-centric workflow?

The naïve approach is to simply run git patch -p and then press ’n’ (no) for each diff hunk. It does not feel particularly effective though.

I found another way, which embodies the spirit of git patch -p more effectively: tig status.

I already use tig every once in a while but wasn’t aware that it could do that.

I won’t try to illustrate the command output here (it’s a TUI); simply give it a try the next time you run git diff or git add.

It’s also possible to stage per file and per hunk changes in the TUI. This operation mode somewhats resemble git-crecord:

git subcommand to interactively select changes to commit or stage

…which I packaged to the Arch User Repository a long time ago, but ended up barely using it. Let’s see whether tig status will stick.

— § —

Reply via email

#dev #git

git: reset default branch

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 16 Oct 2025 17:20:45 +0200

♠ Problem statement: Given an existing repository whose default branch is master, make it become “fresh” (=fully reset it), as if it had just been created.

# backup the current default branch, just in case
git branch backup-old-master
git push origin backup-old-master

# create an orphan branch
git checkout --orphan temp

# remove everything – use one or some of the following, accordingly
git reset --hard
rm {all files}
git rm {all files}

# create an initial commit – c.f. https://perrotta.dev/2025/02/git-blank-commit/
git blank

# delete the old default branch
git branch -D master

# rename temp to master, pick one of the following
git rb master        # this is my alias for "rename branch"
git branch -m master # the native way

# override the current master
git push --force origin master

— § —

Reply via email

#dev #git

git: partially cherry-pick a commit

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 15 Oct 2025 11:08:27 +0200

♠ OR: “cherry-pick a cherry-pick”.

Adam Johnson:

git cherry-pick allows you to copy a commit another branch to your current one.

[…]

One limitation with a straight-up git cherry-pick, as above, is that it always copies the entire commit. If a commit contains multiple changes, but you only want one of them, you’ll need to undo the undesired cherry-picked changes. This can be tedious and error-prone.

The trick is to use the -n (--no-commit) argument to prevent changes from being committed right away.

% git cherry-pick -n {branch or SHA}

This happens to be the default in mercurial with hg graft.

As such, another possibility is to create an alias:

[alias]
  graft = cherry-pick -n

% git graft {branch or SHA}

— § —

Reply via email

#dev #git

git: list branches by recent activity

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 15 Oct 2025 10:59:58 +0200

♠ Tweak ~/.gitconfig:

[alias]
  xl = branch -vv

[branch]
	sort = -committerdate

Result: git xl will print your repository branches sorted by the most recent ones in terms of activity, instead of the alphabetical default.

I have this setting for a long time, and IMHO it’s a better default.

This post by Tekin Süleyman prompted me to share it.

— § —

Reply via email

#dev #git

git: commit with the wrong email

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 14 Oct 2025 13:50:36 +0200

♠ You are sending a PR upstream.

You accidentally commit it with the wrong email.

First, you prevent this mistake from happening again by updating your ~/.gitconfig.

And now you need to fix the most recent commit.

You can easily do so with:

% git commit --amend --reset-author --no-edit

Alternatively, with my aliases:

git uncommit && git recommit

— § —

Reply via email

#dev #git

git: merge two repositories

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 12 Oct 2025 15:52:06 +0200

♠ Daniel Roy Greenfeld, TIL: Merging two git projects:

Of course this task can be done with copy/paste. The challenge there is the loss of git history. All the history of struggles and tribulations are gone. More important is the attribution — unless any and all contributors are made co-authors. But then the volume of attribution isn’t accurate, some one who made one tiny change gets as much credit as the leading contributor.

Adapted to my own words: we will merge “atreides” into “harkonnen”.

cd to harkonnen
git remote add atreides {atreides git repo URL}
git fetch atreides (or git fetch --all)
git merge atreides/master --allow-unrelated-histories # or main, if applicable

Fin.

— § —

Reply via email

#dev #git

git blame: prior commits

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 29 Sep 2025 10:41:15 +0200

♠ Let’s say you want to inspect the history of a given file tracked in a git repository. Straightforward with git-blame(1):

% git --no-pager blame templates/secret-aws-info.yaml
5d478f6cb83b (Kubernetes Astronaut 2025-08-05 10:49:07 -0400  1) {{- if or (eq .Values.config.cloud.provider "aws") (not (.Values.config.externalDNS).enabled) }}
1aeb7c4d7b9b (Thiago Perrotta 2025-04-06 13:11:45 +0200  2) apiVersion: v1
1aeb7c4d7b9b (Thiago Perrotta 2025-04-06 13:11:45 +0200  3) kind: Secret

I am not interested in 5d478f6cb83b though: it was just a refactoring change. How can I look deeper in history? More specifically, I’d like to run git blame on a point in time before commit 5d478f6cb83b:

% git --no-pager blame 5d478f6cb83b^ templates/secret-aws-info.yaml
1aeb7c4d7b9b (Thiago Perrotta 2025-04-06 13:11:45 +0200  1) {{- if or (eq .Values.config.cloudProvider "aws") (not (.Values.config.externalDNS).enabled) }}
1aeb7c4d7b9b (Thiago Perrotta 2025-04-06 13:11:45 +0200  2) apiVersion: v1
1aeb7c4d7b9b (Thiago Perrotta 2025-04-06 13:11:45 +0200  3) kind: Secret

And I could keep going on:

% git --no-pager blame 1aeb7c4d7b9b^  templates/secret-aws-info.yaml
[...]

The Chromium project has a git-hyper-blame(1) script:

Like git blame, but with the ability to ignore or bypass certain commits.

…that enables tracking refactoring/cleanup commits on a permanent basis for skipping blame.

— § —

Reply via email

#dev #git

git: ignore changes to tracked files

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 26 Aug 2025 14:46:44 +0200

♠ Previously.

Given this config file for midnight commander:

% head -n 2 ~/.dotfiles/mc/.config/mc/ini
[Midnight-Commander]
skin=modarin256

…properly installed via stow:

% (cd ~/.dotfiles && stow mc)

Upon opening mc, it writes a lot of configuration settings to that file:

[Midnight-Commander]
skin=modarin256
verbose=true
shell_patterns=true
auto_save_setup=true
preallocate_space=false
auto_menu=false
use_internal_view=true
use_internal_edit=true
clear_before_exec=true
[...]

I could check them into source control, but I do not want to. They are defaults.

So I tell git to leave these additions alone:

% git update-index --skip-worktree mc/.config/mc/ini

Now git status will not show the file.

— § —

Reply via email

#dev #git

ArgoCD: git index.lock issue

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 23 Aug 2025 12:39:14 +0200

♠ Problem statement: Every ArgoCD application is stuck in Unknown state, with the following error:

Failed to load target state: failed to generate manifest for source 1 of 2:
rpc error: code = Unknown desc = failed to initialize repository resources: rpc
error: code = Internal desc = Failed to checkout FETCH_HEAD: failed to checkout
FETCH_HEAD: `git checkout --force FETCH_HEAD` failed exit status 128: fatal:
Unable to create '<path to cached source>/.git/index.lock': File exists. Another
git process seems to be running in this repository, e.g. an editor opened by
'git commit'. Please make sure all processes are terminated then try again. If
it still fails, a git process may have crashed in this repository earlier:
remove the file manually to continue.

It is a lock contention race condition issue within the ArgoCD repo server component, with the git index.lock.

The easiest way to address it is to restart the repo server:

kubectl rollout restart deploy -n argocd argocd-repo-server

Afterwards, refresh all applications in the cluster via the web UI:

click Applications on the left-side nav bar
click Refresh apps at the top
select ALL applications, set refresh type to NORMAL
click refresh

— § —

Reply via email

#dev #git #kubernetes

★ git ll

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 12 Aug 2025 12:50:09 +0200

♠ In my ~/.gitconfig there’s an alias for git log, inspired by Thorsten Ball¹:

[alias]
  ll = "!f() { git log --graph --pretty='tformat:%C(always,yellow)%h%C(always,reset) %C(always,green)%ar%C(always,reset){%C(always,bold blue)%an%C(always,reset){%C(always,red)%d%C(always,reset) %s' \"$@\" | column -t -s '{' | less -XS; }; f"

I wish I could get rid of the shell utilities (column and less), but they’re necessary to properly align the columns.

I also tried to get rid of the function wrapper (f()): it works when you run git ll. However when you run git ll . (=display the commit history from files underneath the current directory only) it fails:

% git ll .
. is a directory

Therefore it’s better to keep it around. I am satisfied with the current form.

The output looks like this (image from upstream):

Update(2025-08-21): The following modification is better² and has no external dependencies:

[alias]
  ll = log --graph --pretty=tformat:'%C(always,yellow)%h%C(always,reset) %C(always,green)%<(25,trunc)%ar%C(always,reset) %C(always,bold blue)%<(20,trunc)%an%C(always,reset) %C(always,red)%d%C(always,reset) %s'

His original configuration is a separate shell function, which is completely unnecessary. A git alias suffices. Keep it simple! ↩︎
In the original implementation, git ll . did not work as expected (i.e. it did not display changes only from the current directory). ↩︎

— § —

Reply via email

#bestof #dev #git

★ git: --no-pager

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 12 Aug 2025 12:21:22 +0200

♠ Let’s say you use color highlighting to visually inspect diffs with git, such as delta or diff-highlight or diffr.

Implication: whenever you run git diff, git show, or any other git command that produces a diff, it will emit colors (typically red and green).

Colors are great for local visual inspection, but they are terrible for sharing. They won’t be carried over with copy-and-paste.

If you intend to share diff output (e.g. to a Q&A site, with teammates), it’s better to emit - and +, as vanilla diff does.

The easiest way to do so is to pass --no-pager to git:

git --no-pager diff a83bc395
git --no-pager show HEAD

For example, a recent commit in my dotfiles:

% git --no-pager show HEAD~1
commit 52b1e91b0f1d93176ec768aa6158974fc401f335
Author: Thiago Perrotta <{redacted}>
Date:   Thu Aug 7 12:00:47 2025 +0200

    fix mr

diff --git bin/.bin/sd-world bin/.bin/sd-world
index c46be0e..44c0b47 100755
--- bin/.bin/sd-world
+++ bin/.bin/sd-world
@@ -58,7 +58,7 @@ esac
 run_if_exists "claude" claude update

 # myrepos
-run_if_exists "mr" mr -d ~ update
+(cd ~ && run_if_exists "mr" mr update)

 # source corp updates if any
 run_if_exists "sd-world-corp"

Note that --no-pager is a git-level option: it should be specified before the git subcommand. The following does not work:

% git show HEAD~1 --no-pager
fatal: unrecognized argument: --no-pager

— § —

Reply via email

#bestof #dev #git

git: developer certificate of origin (DCO) sign-off

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 24 Jul 2025 12:37:31 +0200

♠ The Developer Certificate of Origin (DCO for short) is often required when sending out PRs upstream.

For example, contributions to the Linux kernel mandate it. Other projects too.

It’s even possible to enforce it via Github Actions.

Suppose that you sent a PR with a single commit but forgot to sign it off. You can amend it with:

git rebase HEAD~1 --signoff
git push --force-with-lease origin [branch]

Or you can do it proactively, at commit time:

git commit [-s | --signoff]

It is often discouraged to have git automatically do it:

Adding the Signed-off-by trailer to a patch should be a conscious act and means that you certify you have the rights to submit this work under the same open source license.

In practice, a sign-off is an ordinary git footer:

Signed-off-by: John Doe <john@example.com>

— § —

Reply via email

#dev #git

Markdown headings and git comments

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 08 Jul 2025 13:18:09 +0200

♠ Our team uses a PR template that resembles the following:

## Summary

<!-- Provide a clear and concise description of the changes.
Provide a link to the corresponding PR in other repositories if applicable. -->

## Jira Task

- [ ] No ticket needed

https://acme.atlassian.net/browse/XXX

## Cluster(s) Affected

<!-- List the clusters affected by this change -->

## Impact

<!-- Describe the impact of these changes. Will this require downtime? Are there
any performance considerations? -->

## Testing

<!-- Describe how you've tested these changes -->

Previously I wrote about how to automatically incorporate github pull request templates in git commit (COMMIT_EDITMSG).

It turns out there’s one caveat with this approach.

Markdown headings¹ (## for <h2>) use the same character as git line comments (#) for commit messages.

As a side effect, when pulling up the template locally with a plain git commit, the headings do not show up in the final commit message.

This can be worked around by using gh pr create instead, but it breaks my setup.

Another workaround is to convert the headings to use ---- markers, for example:

Summary
-------

<!-- Provide a clear and concise description of the changes.
Provide a link to the corresponding PR in other repositories if applicable. -->

Update: A teammate pointed out the following workaround, which is the most elegant of them:

core.commentChar:

Commands such as commit and tag that let you edit messages consider a line that begins with this character commented, and removes them after the editor returns (default #).

If set to “auto”, git-commit would select a character that is not the beginning character of any line in existing commit messages.

And that’s exactly what I did:

% git config set --global core.commentChar "auto"

The effect, it automatically picks ; as the comment character:

## Summary

<!-- Provide a clear and concise description of the changes.
Provide a link to the corresponding PR in other repositories if applicable. -->

; Please enter the commit message for your changes. Lines starting
; with ';' will be ignored, and an empty message aborts the commit.
;
; On branch master
; Your branch is up to date with 'origin/master'.
;
; ------------------------ >8 ------------------------
; Do not modify or remove the line above.
; Everything below it will be ignored.

I am always forgetting whether to call them “headings” or “headers”. ↩︎

— § —

Reply via email

#dev #git

Oh Shit, Git!?!

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 19 Jun 2025 13:55:45 +0200

♠ https://ohshitgit.com/ by Katie Sylor-Miller:

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can’t search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem.

So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english.

I love these websites created with the sole purpose of filling in the void of tool usability.

Other notable examples from the top of my head:

— § —

Reply via email

#dev #git

★ git delta

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 16 Jun 2025 13:28:23 +0200

♠ I’ve been using the venerable diff-highlight script to power various git diff operations in the terminal. It is a decent improvement on top of stock git diff, but it’s somewhat of an annoying maintenance burden to manage it across various environments, as it’s installed in different ways on various systems:

#!/bin/sh

if hash git >/dev/null 2>&1; then
	# git-diff-highlight: alpine:/usr/bin/, arch, debian
	path_munge "/usr/share/git/diff-highlight" "/usr/share/doc/git/contrib/diff-highlight"

	# brew
	if hash brew >/dev/null 2>&1; then
		path_munge "$(brew --prefix)"/share/git-core/contrib/diff-highlight
	fi

fi

Thus I decided to migrate to git-delta, which is:

quite popular
written in Rust™¹
available in all package managers I’m interested in – hence it’s one install command away from my system, no need for extra configs <== And this is the main reason I wanted to migrate to it.

On macOS, the package is called git-delta whereas the binary is called delta:

% brew install git-delta
% brew ls git-delta | grep bin/
/opt/homebrew/Cellar/git-delta/0.18.2_3/bin/delta

The integration with git is as follows:

% grep -E '\[core\]|pager =|delta' ~/.gitconfig
[core]
        # delta > diff-highlight > plain cat
        pager = "delta --diff-highlight 2>/dev/null || ((diff-highlight 2>/dev/null || cat) | ${PAGER:-less})"

It falls back to diff-highlight when delta is not available.

delta is quite configurable:

% grep -EA3 '\[delta\]' ~/.gitconfig
[delta]
        navigate = true
        side-by-side = false
        line-numbers = true

One caveat of using delta: the git diff output is not suitable for sharing, as it does not contain diff markers, relying on colors instead. See this post for a workaround.

Update(2025-09-07): I’ve been finding delta quite pleasant to use.

Always an (over)hyped reason to migrate, but, oh well… ↩︎

— § —

Reply via email

#bestof #dev #git