DEV Community: Kamon Ayeva

Disk full? broot's whale-spotting mode plus Ctrl-G turns your cleanup into one command

Kamon Ayeva — Fri, 25 Sep 2026 18:59:48 +0000

Every engineer knows the disk-full afternoon. The build or the backup job fails, and you end up in the same loop using du -sh and rm:

du -sh */ | sort -h
rm that-one-cache-dir
du -sh */ | sort -h
rm another-thing

That works but, since the listing you get is flat, you see directory totals, not the files inside them. And you delete one directory at a time, with no way to collect a set of files, review the set, and delete it in one go.

This article is about a workflow I use instead, built on broot's staging area:

br -w lists files sorted by size,
Ctrl-G collects the files you want to delete into a review panel,
:rm deletes the whole set.

Let's explore the details, while running the workflow in a real directory.

Step 1: get the sorted view with `br -w`

As a reminder, broot is launched using br, the shell function; launching plain broot works too, but br is what makes cd work (when you are navigating the tree and want to land in the contextual folder using the :cd verb).

The -w flag is for the whale-spotting mode: it sorts files and directories by size, biggest first. Using this feature, when a disk fills up, you can see the files that are using the space.

br -w

As a result, the tree shows each directory with its total, and you expand any of them by moving down with the arrow keys and hitting Enter on a folder.

The difference from using du | sort -h is that you're inside one interactive tree, moving from the big directories down to the big files inside them, without running a new command per level.

Step 2: build the set of files to delete with `Ctrl-G`

Next, move the cursor to a file you want to delete and press Ctrl-G. A marker appears next to the filename, and a second panel opens on the right; it's the staging area, showing the files you have collected so far. Press Ctrl-G on each new file you want to delete, and it is added to that area. And you can remove a file from the set, by pressing Ctrl-G on it a second time.

Keep navigating the tree and staging files as you go. The panel refreshes everytime there is a staging or unstaging action, showing the files you collected and their total size. You can see directly how much space can freed by deleting the set, instead of guessing.

Step 3: review the set, then delete it with `:rm`

One detail that confused me at first: when the staging panel opens, it does not take the focus. The focus stays on the tree panel, so you can keep navigating. This means that a verb you type applies to the tree panel's selection, not the staged set, until you move the focus.

The keystroke to move the focus is Ctrl-Right. Once the staging panel is focused, you can review it like any broot panel: scroll it, filter it, and unstage files you no longer want. The whole deletion set is visible in one place before anything is gone.

In case the Ctrl-Right keystroke do not reach broot, as it happens on my macOS, just use the "typed verb" fallback: :panel_right. And, for going back to the tree panel, there is its counterpart :panel_left_no_open.

When the staged set is right, type the verb needed for deletion (:rm) and read the status line before you go ahead by hitting Enter.

:rm
Enter

One caveat from my run (using both broot 1.58.0 on macOS and broot 1.58.0 on Ubuntu 24.04): with several files staged and the staging panel focused, the status line showed only one of them as selected — but pressing Enter removed the whole staged set. So the status bar report is partial, but the staging panel itself is the true picture of what will be deleted.

As you can see, using broot this way, the cleanup loop becomes: list (stage), review, delete.

Before you script the cleanup

Of course you could also use find with a size filter, or a du piped to xargs rm. And for a recurring need, scheduling that command (cron or equivalent) is the right solution.

But the first few times, you want to do it interactively. You don't yet know what is big and why, so the decision about what to delete needs a human check: is that node_modules directory obsolete? is that log file still being written? does that .db file belong to something you forgot you installed? The staging feature shows you the directory file by file, and you understand what is safe to delete. When the pattern becomes obvious (things like old logs past 90 days), then write a script for exactly that. You will know what the script touches, because you staged that set by hand.

In conclusion, do it interactively first, and script it once you know the rules for what to delete. The interactive session is how you identify the rules.

When the keystrokes do nothing

It might happen that Ctrl-G or Ctrl-Right does nothing in your terminal. Some terminals intercept those key combinations before broot receives them. But the workflow does not depend on the keys: each one has a typed verb that does the same thing.

:toggle_stage           # or :stage / :unstage — equivalent to Ctrl-G
:open_staging_area      # or :osa — force the staging panel open
:clear_stage            # or :cls — empty the staging area, start over
:panel_right            # focus the staging panel (if open)
:panel_left_no_open     # focus the tree panel

If a keystroke does not work, type the verb instead.

Other verbs to use on the staged set

While rm is the disk-cleanup verb, the staging set works with anything:

:cp {dest}: copy the whole set somewhere first, then delete it; useful for a backup before the cleanup.
:mv {dest}: move the set to another volume instead of deleting it.
:chmod +x: apply a mode to every staged file, when the task is about permissions instead of space.

There is one verb that works differently: :zip takes the whole staged set as the arguments of a single zip command, so the resulting archive holds everything. While the verbs above run once per staged file, :zip runs once for the whole set.

# Inside broot, after staging several files:
:zip /tmp/backup

That's the archive-first variant of the workflow: br -w, stage the big old logs, run one :zip (in the above example, this creates /tmp/backup.zip), then decide about deletion once the archive exists.

This article expands issue #9 of my newsletter, Shellcraft — one piece of terminal craft per week.

Lazygit's M Key Hides Four Merge Options — Here's the Git History Each One Leaves Behind

Kamon Ayeva — Sat, 12 Sep 2026 12:37:43 +0000

I use lazygit daily, and for a long time M was just "the merge key". Press it, pick the option, the merge happens. It took me a while to actually slow down and pay attention to the options in the menu. Each option runs the same merge, but the commit graph left behind is different, and that influences the git history.

So I did what I do with any keystroke I don't fully understand: I built a throwaway repo, pressed M one option at a time, and read the history graph after each one. This article is the result — each option, the history it leaves, and at the end, the two git log commands that show you the merge shape of any repo you care about.

The one key with four options

In lazygit's branches panel, put your cursor on the branch you want to merge in (the source branch) and press M. A panel titled Merge opens with four options (in lazygit version 0.62.2):

Regular merge (fast forward) — m (fast-forwards when possible, otherwise creates a merge commit)
Regular merge (with merge commit) — n (always creates a merge commit)
Squash merge and leave uncommitted — s
Squash merge and commit — S

Same panel, four different histories. Let's experiment with each one.

Set up a throwaway repo

Everything below reproduces on any machine with git and lazygit installed (brew install lazygit or apt install lazygit):

mkdir /tmp/merge-modes && cd /tmp/merge-modes
git init && git commit --allow-empty -m "init"

# a feature branch with three commits
git checkout -b feature
echo one > a.txt && git add . && git commit -m "feature: step one"
echo two > b.txt && git add . && git commit -m "feature: step two"
echo three > c.txt && git add . && git commit -m "feature: step three"

git checkout main

Open lazygit in this repo, go to the branches panel, put the cursor on feature, and press M. After each experiment, run git log --oneline --graph in the shell and look at the shape. Then git reset --hard HEAD@{1} to try the next option.

Regular merge (fast forward) — `m` option

This is the default in the M menu, and it behaves differently depending on the state of the target branch:

If main has not moved since you cut feature, git can fast-forward: main's pointer slides up to feature's tip. No new commit is created.
If main has moved on, git cannot fast-forward, and a merge commit is created instead (same shape as the no-fast-forward option we discuss next).

Our throwaway repo is in the fast-forwardable state, so pressing m produces the linear graph:

* feature: step three
* feature: step two
* feature: step one
* init

The branch itself leaves no trace. That is the nice thing and the cost at the same time: the history looks as one straight line, and nothing in it says "these three commits arrived together as one reviewed unit." Use this option when you have a really short-lived branch and the target branch did not move; the moment the target has its own commits, you get the merge-commit graph instead.

Regular merge (with merge commit) — `n` option

This one always produces a merge commit with two parents, regardless of whether the target has moved: the previous tip of main and the tip of feature. Press n when you specifically want the "a branch landed here" marker on the graph. The result looks like this:

*   merge branch 'feature' into main
|\
| * (feature) feature: step three
| * feature: step two
| * feature: step one
|/
* init

The three feature commits survive as themselves, and the merge commit is a permanent marker that says "a branch landed here." That marker is the point of this option. If you ever want to read the history as a series of landed branches, one entry per merge, git log --first-parent gives you exactly that view, and the merge commit is what makes it work.

The cost: the graph has merge knots, and anything that assumes a linear history (such as some revert flows) gets slightly more work to do.

Squash merge — `s` and `S` options

Both squash options collapse the source branch's commits (the three feature: step commits) into one new commit on the target. The intermediate commits on the source branch do not appear on the target. Only the one squashed commit does. So git log on the target cannot show how the source branch evolved, step by step. The trade is: you gain a clean, one-commit-per-change history, but you lose the record of the journey.

After S, the target's history looks like this:

* squash merge feature into main
* init

After s, git log on the target is unchanged from before the merge — the squashed changes land in your working tree, staged but uncommitted. You write the commit message yourself, then commit.

In practice s is the one I reach for when the commit message matters, which is most of the time: after the squash, that message is the only record of the branch that survives. S is the quick path.

Reading the shape of a repo's past merges

Once you know the four shapes, you start seeing them in real repos. Run these on any repo with some history (a long-lived side project is a good start):

git log --oneline --merges -20
git log --oneline --first-parent -20

--merges shows only merge commits, while --first-parent walks only the target side of each merge, which is the "one entry per landed change" view. Check the two lists together:

`--merges` shows	`--first-parent` shows	The repo's merge style
many merge commits	each merge is one entry	merge commits (no-fast-forward, or `m` when the target has moved)
few or no merge commits	one commit per landed branch, "squash"-style messages	squash (`s` or `S`)
no merge commits, granular commits	linear history	fast-forward (`m` when the target is quiet) or direct pushes

I ran these on my own old repos and found exactly what you'd expect from someone who never thought about it: a mix. Squash here, a merge commit there, a fast-forward when the target happened to be quiet. No single shape, because no single decision was ever made. The commands are useful precisely because the shape is usually undocumented — the history is the only record of the choice, whether it was deliberate or not.

Picking one and living with it

Pick one shape (and merge option) and keep to it. Six months from now, you may have to revert a bad change or read the history to understand why something was done — in those situations, the job is easier when the history has a consistent shape, and harder when it mixes all four options at random.

If you pick wrong, the merge commit is just a commit: in the shell, do git reset --hard HEAD@{1}, or in lazygit, from the commits panel, put the cursor on the bad commit, and press z to soft-reset. And if the merge produced a conflict, there is no abort path — only forward: lazygit opens the conflict view, you resolve each hunk, do esc back to the files panel, and the merge flow continues from there.

That's what is behind lazygit's M panel and the four types of history its options leave. Pick whichever one matches the shape you want your future self to read.

This article expands issue #7 of my newsletter, Shellcraft — one piece of terminal craft per week.

I Test Every Terminal Claim Before I Publish It

Kamon Ayeva — Thu, 10 Sep 2026 18:35:51 +0000

Hello fellow devs.
I'm Kamon Ayeva. I've spent 20+ years building and deploying web applications, and most of that time in production contexts, where the terminal is where you debug, deploy, and fix things under pressure.

I remember a long time ago when a colleague advised to switch to Linux if I wanted to be more productive. And later, like many developers, I switched to macOS as my OS of choice.

My avenues of learning and teaching have always been inspired by: productivity, frictionless collaboration, the terminal and the power of the CLI. That's where my writing comes from: craft I picked up, and repeated, because a job needed it.

I write a weekly newsletter called Shellcraft, one piece of terminal craft per issue: fzf, broot, lazygit, bat, DuckDB, the shell idioms in between, etc. I'm also the author of The Modern CLI Stack, a free book about the modern terminal toolkit.

This is my first post here, and I want it to introduce the rule behind everything I write, because it's the reason the newsletter is worth your time:

I run every claim on my own machine before it's published.

Roughly one in five claims I draft turns out to be wrong when I test it. Not typos, but plausible-sounding errors. A shortcut that the current version doesn't bind anymore. A config format I half-remembered from an older release. A verb that the docs mention but the binary doesn't ship. Last month I drafted an issue about a tool's panel workflow, ran the session walk before publishing, and discovered the step the whole issue was built around didn't happen on my machine. I spent time rewriting the issue around what actually happens, and I was happy with shipping that version.

The drafts that pass without corrections are the dangerous ones. So before each issue goes out, I write a small verification guide for it (steps to reproduce it, the expected output, etc). It's a private test file, and running it is one of the last steps before publish.

Why am I telling you this in my intro post here? Because it's the promise I'm making to this community. I plan to post here, at least once a month, expanded versions of what I cover in the newsletter, the same way I write it.

If that's the kind of thing you want in your feed, the newsletter sends it weekly. The book is the free full toolkit.

Happy to be here.
What's a terminal claim you believed for years that turned out to be false? Or a suggestion for something I should feature in the newsletter?