Reorder, squash, and drop — like a stack of cards
Your branch is a stack of commits. Interactive Git Log lets you rearrange that stack visually in VS Code, then runs the interactive rebase for you.
Think in stacks, not just branches
A feature branch is really a stack of commits — each one a layer of work sitting on the ones below it. The term comes from the stacked-diff workflow used at companies like Meta, where IGL's smartlog design originated: instead of one giant branch diff, you build a sequence of small, reviewable commits and keep them tidy as you go.
Working that way requires one thing traditional Git tooling makes painful: the ability to edit the stack — move a fix down next to the commit it fixes, combine two half-steps into one, delete an experiment that didn't pan out.
The stack editor
On any branch with multiple commits, IGL shows an Edit stack button. It opens a dialog listing your commits as a stack you can manipulate directly: reorder by moving commits up and down, squash a commit into its parent, or drop one entirely.
Press Save changes and IGL translates your edits into a git interactive rebase and runs it. The todo file, the pick/squash/drop vocabulary, the fear of mistyping a line — all of it replaced by direct manipulation.
Clean history before the PR
The payoff comes at review time. The branch you worked on — with its "wip", "fix test", and "actually fix test" commits — becomes a short sequence of deliberate changes. Your reviewer reads a story instead of an archaeology dig, and six months from now git bisect lands on a commit that means something.
A practical rhythm: commit freely while you work (staging and amending are one click anyway), then spend ninety seconds in the stack editor before pushing.
Squash vs fixup vs drop
In rebase vocabulary: squash combines a commit into the one before it and merges their messages; fixup does the same but throws the message away; drop deletes the commit and its changes entirely. IGL's stack editor covers these operations visually — you pick what survives, it works out the rebase.
Frequently asked questions
Is editing my stack safe?
Stack editing rewrites local history, so the usual rebase rule applies: do it freely on branches only you are working on, and avoid it on branches others have pulled. Until you force-push, everything stays local — and git reflog can restore the previous state.
What if reordered commits conflict with each other?
If two commits touch the same lines, reordering them can produce conflicts when the rebase replays — the same as any rebase. IGL surfaces them with its inline conflict checklist so you can resolve and continue.
Why squash commits at all?
Reviewers read commits, not diffs of diffs. A branch that tells a clean story — one logical change per commit, no "fix typo" noise — gets reviewed faster and bisects better later. Squashing is how the sausage-making disappears before anyone sees it.