DEV Community: Evan

git pull --rebase deleted your commit: the rescue and the reason

Evan — Tue, 15 Sep 2026 14:00:00 +0000

This morning git pull --rebase printed a success line and deleted the
commit you pushed yesterday. No conflict, no error, no prompt. The
working tree is clean, the branch says up to date, and the commit is on
no branch anywhere: not yours, not the remote's.

Nothing in that story fails, which is what makes it dangerous.
Reproducing it takes two clones and four commits. Watch it happen, get
the commit back, then meet the rule that decided your pushed work was
disposable. Git 2.51, stock configuration, throughout.

Two clones, one branch

Your teammate started the branch search and pushed two commits; you
cloned and joined. Your contribution is a ranking fix:

$ git log --oneline
97d747a Index file paths
5d48fd5 Add search command
$ git add ranking.js
$ git commit -m "Rank exact matches first"
[search 5a818d0] Rank exact matches first
 1 file changed, 1 insertion(+)
 create mode 100644 ranking.js
$ git push
To …/origin.git
   97d747a..5a818d0  search -> search

5a818d0 is on the remote now; anyone who fetches gets it. The push
also did one other thing, quietly, in your own clone. It comes back
when we get to the why.

The force push you never saw

Your teammate's clone hasn't fetched since before your push, so their
branch still ends at 97d747a, and they've just committed a filter:

$ git add filters.js
$ git commit -m "Match on file type"
[search d5c109a] Match on file type
 1 file changed, 1 insertion(+)
 create mode 100644 filters.js
$ git push
To …/origin.git
 ! [rejected]        search -> search (fetch first)
error: failed to push some refs to '…/origin.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

The work the remote contains that they do not have is your commit. The
refusal is Git protecting it, and the hint says how to take it in. They
read the refusal as friction:

$ git push --force
To …/origin.git
 + 5a818d0...d5c109a search -> search (forced update)

The last post was about
this moment from the pusher's side, and about the flags that would have
refused it. Today the interest is on your side of the wire, because
nothing so far has touched your clone. The remote lost its copy of
5a818d0; yours is intact, checked out, one git log away. The deletion
that sticks is going to be yours.

The pull

$ git pull --rebase
From …/origin
 + 5a818d0...d5c109a search     -> origin/search  (forced update)
Successfully rebased and updated refs/heads/search.
$ git log --oneline
d5c109a Match on file type
97d747a Index file paths
5d48fd5 Add search command
$ git status
On branch search
Your branch is up to date with 'origin/search'.

nothing to commit, working tree clean

Your commit is gone, and every signal reads as routine. The fetch did
disclose what it saw: one (forced update) line, the same dialect the
last post decoded. The rebase then proceeded as if that line settled
things. "Up to date" here means agreeing with a remote that was
force-pushed a minute ago.

The rescue

Reason later; rescue the commit first. The branch's reflog (the local diary of
the positions search has held in your clone) still lists it:

$ git reflog search
d5c109a search@{0}: pull --rebase (finish): refs/heads/search onto d5c109ab3f4881e4f58b8de14947c0cb23a202ee
5a818d0 search@{1}: commit: Rank exact matches first
97d747a search@{2}: clone: from …/origin.git

search@{1} is the branch as it stood before the pull rewrote it. If
your tree isn't clean, git stash --include-untracked first —
--hard throws away uncommitted changes. Then move back:

$ git reset --hard search@{1}
HEAD is now at 5a818d0 Rank exact matches first
$ git log --oneline
5a818d0 Rank exact matches first
97d747a Index file paths
5d48fd5 Add search command
$ git status -sb
## search...origin/search [ahead 1, behind 1]

If you'd already committed new work on top of the pulled branch
before noticing, reset would take it down with the pull's result; in
that case git cherry-pick 5a818d0 brings the lost commit onto the
current state instead. A branch repaired that way already sits on
top of origin/search, so there is nothing left to integrate: skip
the reset below, git push, and git stash pop if you stashed
at the start.

Ahead 1, behind 1 is the divergence the pull was supposed to resolve,
now out in the open: you have a commit missing from the remote, the
remote has one you haven't integrated. If you took the reset path, that
gets resolved in Integrating it properly, below. First, the reason.

Why the rebase threw it away

A rebase pull is a fetch, then a rebase of your branch onto the updated
origin/search. The rebase's first job is drawing a boundary: which
commits are yours to replay onto the new tip, and which belonged to the
old upstream, where replaying would only resurrect discarded history.
Git has two ways to draw that boundary, and they disagree about you:

$ git merge-base origin/search search
97d747a8a37a3b4cf5d3032ff2504761c898646e
$ git merge-base --fork-point origin/search search
5a818d0272d94df7a2b447d349402105f8df8c0a

Plain merge-base answers from the commit graph: the two histories
part ways after 97d747a, so everything past it on your branch is yours
to replay — one commit, 5a818d0. That is the boundary an explicit
git rebase origin/search would use.

--fork-point is what git pull uses, and it consults something the
graph doesn't have: the reflog of your remote-tracking ref.
origin/search is your clone's private record of the remote branch,
and it keeps a diary of its own:

$ git reflog origin/search
d5c109a refs/remotes/origin/search@{0}: pull --rebase: forced-update
5a818d0 refs/remotes/origin/search@{1}: update by push

update by push. Your push didn't just send the commit; it recorded,
in your own clone, that the upstream branch has stood at 5a818d0. The
fork-point rule treats every position in that diary as upstream
history — and the upstream has since moved off 5a818d0, so by its
reading, the upstream considered your commit and threw it away. The
boundary lands on the commit itself, the replay set is empty, and the
rebase does exactly what it was asked, for the branch it believed it
was looking at.

The rule exists for a real case. If a maintainer rewrites a branch
under commits you have not pushed, fork-point is what stops the
rebase from replaying the abandoned upstream commits underneath your
work: no duplicates, no phantom conflicts from history the rewrite
meant to delete. It guards unpushed work sitting on rewritten history.
The trap is that the diary records positions, never ownership. A commit
you pushed and a commit the upstream abandoned are indistinguishable in
it, and your own push is what put yours on the list. That is the quiet
other thing the push did back in the first block.

The flag that doesn't exist

git rebase can be told not to do this: --no-fork-point, or
rebase.forkPoint=false in config. Neither survives contact with
git pull. The flag first:

$ git pull --rebase --no-fork-point 2>&1 | head -2
error: unknown option `no-fork-point'
usage: git pull [<options>] [<repository> [<refspec>...]]

The config setting looks like it should reach the rebase that pull
runs underneath. Watch it not do that: this next run has
rebase.forkPoint=false set, and GIT_TRACE prints what pull executes:

$ GIT_TRACE=1 git -c rebase.forkPoint=false pull --rebase 2>&1 | grep -oE "run_command: git (merge-base|rebase).*"
run_command: git merge-base --fork-point refs/remotes/origin/search search
run_command: git rebase --no-autostash --onto d5c109ab3f4881e4f58b8de14947c0cb23a202ee 5a818d0272d94df7a2b447d349402105f8df8c0a
$ git log --oneline
d5c109a Match on file type
97d747a Index file paths
5d48fd5 Add search command

Gone again, config and all. The trace is the explanation. Pull computes
the fork point itself (the first line) and hands the verdict to rebase
as an explicit --onto: rebase onto d5c109a, replaying whatever
follows 5a818d0. By the time rebase would consult rebase.forkPoint,
the decision is already spelled out in its arguments, and a setting
can't override an argument. As of Git 2.51 there is no pull-side flag
and no config that reaches this: every rebase pull across a rewritten
upstream gets the fork-point verdict whenever the reflog can supply
one — and your own push made sure it can.

Integrating it properly

So the fix has to happen outside the pull. First, back to the rescued
commit — by hash this time: if you skipped the traced demonstration,
your reflog positions differ from mine, and the hash is correct on
either path. Then rebase onto the explicit name — naming the upstream
is what makes rebase use the plain merge-base boundary:

$ git reset --hard 5a818d0
HEAD is now at 5a818d0 Rank exact matches first
$ git rebase origin/search
Successfully rebased and updated refs/heads/search.
$ git log --oneline
aeae0fd Rank exact matches first
d5c109a Match on file type
97d747a Index file paths
5d48fd5 Add search command
$ git push
To …/origin.git
   d5c109a..aeae0fd  search -> search

Your change is back on the branch: aeae0fd, a new hash because the
parent changed, same message and content, sitting on top of your
teammate's work, published with an ordinary fast-forward push. Both
commits survive. This is what the pull would have done had it drawn the
boundary from the graph instead of the diary. If you stashed at the
start, git stash pop brings that work back; the incident is over.
(A bare git rebase with no upstream argument defaults to the same
fork-point rule as pull, so name the upstream when it matters.)

A (forced update) line in any fetch or pull output is the only
warning you get. When you see it, stop pulling by reflex. Read what moved
(git log --oneline origin/search), check whether your own pushed
commits are still part of it, and integrate with an explicit
git rebase origin/<branch> so the boundary comes from the graph.

Or don't do any of this

The check you just ran by hand is two read-only commands: fork point
against merge base, with the at-risk commits sitting between them. A
Git client can afford to run that check before every rebase pull.

GitDesktop runs it as a pre-flight check. When the two
answers agree, the pull proceeds as normal. When they disagree, it
stops before the rebase and asks "Keep or drop these commits?", with
each at-risk commit listed by id, subject, and date. Keeping them
replays them on top of the rewritten upstream, the same move as the
explicit rebase above, and it's the focused default. Dropping them is
allowed too (sometimes the rewrite really did mean to take your commit
with it), and a drop is recorded in Operation history rather than
trusted to memory. The transcript above, with its one success line,
becomes a question with the evidence attached.

A success message tells you the plan worked. It never tells you the
plan was right.

Work on two branches at once with git worktree

Evan — Thu, 10 Sep 2026 14:00:00 +0000

You're an hour into a parser rework. Half the call sites are on the new
signature, the tests are red on purpose, and there's an untracked file
of notes you'd rather not explain. Then a bug report lands: production
crashes on a null payload. The fix belongs on main, and it can't wait
for your rework.

So you do the stash dance: git stash, switch, fix, push, switch back,
git stash pop, and hope the pop applies. Usually it does. The times
it doesn't, you're resolving conflicts inside work that was
half-finished on purpose, the one place where you have no idea what
"correct" looks like.

Underneath the dance sits an assumption: a repository has one working
tree, so branches take turns using it. That assumption became optional
in 2015, when Git 2.5 shipped git worktree.

A second folder, same repository

Leave the mess exactly where it is:

$ git branch --show-current
feature
$ git status --short
 M src/parser.js
?? notes.md
$ git worktree add -b fix-crash ../hotfix origin/main
Preparing worktree (new branch 'fix-crash')
branch 'fix-crash' set up to track 'origin/main'.
HEAD is now at 812aeba Expand usage docs (#12)

That created a linked worktree: a second working tree in its own
folder, attached to the repository you ran the command from.
-b fix-crash cuts the branch, ../hotfix is where the checkout
goes, and origin/main is the base (fetch first, so it sits at the
remote's tip when you branch off it). The tracking line is ordinary
branching-from-a-remote behavior; nothing about it is worktree-specific.

"Attached" is the key word. This is not a second clone. There is one
object database, one set of branches, one config, one list of
remotes; the new folder holds a checkout and nothing else:

$ git worktree list
…/app     542eaf6 [feature]
…/hotfix  812aeba [fix-crash]
$ cat ../hotfix/.git
gitdir: …/app/.git/worktrees/hotfix

The .git in a linked worktree is a file, not a directory: a pointer
back to the real repository, which keeps the linked checkout's
bookkeeping under .git/worktrees/. What each worktree does own is a
HEAD, an index, and its working files. The split runs along one line:
the things that make up "where I'm standing" are per-worktree, and the
things that make up "the repository" exist once.

The fix, without the dance

A fresh worktree checks out tracked files only, so ignored files
like node_modules and build output start absent; this one-line
fix doesn't need them. Open ../hotfix in a second editor window,
make the fix, and commit it over there:

$ git -C ../hotfix commit -am "fix: guard null payload"
[fix-crash 0a21336] fix: guard null payload
 1 file changed, 1 insertion(+)
$ git log --oneline -1 fix-crash
0a21336 fix: guard null payload
$ git push origin fix-crash
To …/origin.git
 * [new branch]      fix-crash -> fix-crash
$ git status --short
 M src/parser.js
?? notes.md

Look where the last three commands ran: in your original checkout, the
seat you never left. The commit was made in ../hotfix, yet from the
feature seat it was already there: not fetched, not copied, just
there, because there is only one repository. The push works from
either folder for the same reason. And your own working tree sat out
the whole thing: the same modified file, the same untracked notes,
the dev server still warm. Open a PR for fix-crash and get back
to the rework.

One branch, one checkout

If both folders share the branches, can they share a branch?

$ git switch fix-crash
fatal: 'fix-crash' is already used by worktree at '…/hotfix'

No, and the refusal is the design. A branch is one shared pointer, but
each worktree built its index and working files against wherever its
own HEAD stood. If two worktrees stood on fix-crash and one of them
committed, the other would be standing on history that had moved under
it. Git refuses up front instead.

You've met this guard before if you've read the branch-updating
post: it's the same
rule that stops git fetch origin main:main while main is checked
out anywhere, and the same reason git branch -D declines to delete
a branch a worktree is using; in every case the error names the
folder to go look at. When you want the files without any branch
question at all, add the worktree with --detach — a checkout
pinned to a commit, no branch involved.

The stash is shared too

The stash list is a ref, and it belongs to the repository, not to
any one checkout:

$ git stash push -m "parser rework, half done"
Saved working directory and index state On feature: parser rework, half done
$ git -C ../hotfix stash list
stash@{0}: On feature: parser rework, half done

One list, visible from every seat. Pop it back from the seat that
pushed it. Nothing enforces that: a stash applies to whichever
working tree runs the pop. If you use worktrees and stashes together,
the "On feature" prefix and a real message are what tell you, later,
where a stash came from and where it belongs.

Folders are disposable, the bookkeeping isn't

The fix is pushed and the PR is open, so the hotfix worktree has
done its job:

$ git worktree remove ../hotfix
$ git branch --list fix-crash
  fix-crash

remove succeeds without a word: the folder and the repository's
record of it are gone, and nothing else; the branch survives. If the
worktree still had modified or untracked files, the same command
refuses: contains modified or untracked files, use --force to delete it.

What you shouldn't do is delete the folder by hand. Git copes with
that too, though:

$ git worktree add --detach ../scratch
Preparing worktree (detached HEAD 542eaf6)
HEAD is now at 542eaf6 wip: extract tokenizer
$ rm -rf ../scratch
$ git worktree list
…/app      542eaf6 [feature]
…/scratch  542eaf6 (detached HEAD) prunable
$ git worktree prune
$ git worktree list
…/app  542eaf6 [feature]

The folder died; the record remained, flagged prunable, until
git worktree prune collected it.

One more state you'll meet eventually: a worktree on a USB stick or a
network share isn't always mounted, and from the repository's side an
unmounted folder looks exactly like a deleted one; a prune would sever
it. git worktree lock --reason "on the USB drive" ../usb protects
it: a locked worktree can't be pruned, and remove refuses, quoting
your reason back at you.

Moving is allowed, with one asymmetry. git worktree move relocates a
linked worktree cleanly, while moving the main repository folder by
hand breaks every link; git worktree repair, run from the new
location, mends them.

Or don't do any of this

The post you're reading was written in a worktree. GitDesktop's
repository has a website lane, and on my machine that lane lives in a
linked worktree, so drafting a post never touches the branch the app
work is standing on. The client managing those worktrees is
GitDesktop, which I build. Its Worktrees… dialog
carries the whole lifecycle (add, open, rename, lock, promote,
delete), with the guards built in: deleting a dirty or locked
worktree asks first, and a moved repository folder gets re-connected
by its Repair links button.

Two of its choices map straight onto the rules above. Switch to a
branch that lives in another worktree and you don't get the
already used by worktree error: the branch is badged, and choosing
it opens that folder instead. And Promote to main workspace
collapses the sequence the one-checkout rule forces (remove the
worktree first, then check its branch out in the main workspace)
into one action, once the worktree is clean.

Branches take turns only when you give them one folder to take turns
in. The habit outlived the constraint by a decade.

Update a Git branch without checking it out

Evan — Mon, 07 Sep 2026 14:00:00 +0000

Your pull request just merged. You're already on the next branch, and
now your local main is stale: the merge landed on the remote, not in
your clone. Sooner or later you'll cut a branch from main, rebase onto
it, or just read it, and you'd rather all of that see today's history
instead of last week's.

The move everyone knows is to go visit: git switch main, git pull,
git switch -. It works. It also checks out main for the privilege of
running one fast-forward, and a checkout stopped being free
years ago: dev servers restart, watchers
refire, generated files churn, and if .gitignore changed in the meantime
you come back to a wall of untracked files. Two context switches
to move one pointer.

Git can move a branch you're not standing on. It has been able to all along.

The colon in the refspec

git fetch takes refspecs: <source>:<destination>. The source names a
ref on the remote; the destination names the ref in your repository that
the fetched history lands in. The everyday git fetch origin gets its
refspec from your config: +refs/heads/*:refs/remotes/origin/*, remote
branches in, tracking refs out. Write a refspec by hand and the
destination can be a local branch:

$ git branch --show-current
feature
$ git log --oneline -1 main
e7d9e76 init
$ git fetch origin main:main
From …/origin
   e7d9e76..114c7a5  main       -> main
   e7d9e76..114c7a5  main       -> origin/main

Two updates from one fetch: main:main moved your local branch, and
because its source is covered by the configured refspec, Git updated the
matching tracking ref origin/main too. And nothing else moved at all:

$ git log --oneline -1 main
114c7a5 Add lexer (#13)
$ git branch --show-current
feature
$ git status --porcelain
$

Fetch never touches your index or your working tree. No checkout, nothing
restarted, and main is current: git switch -c next main now starts
from today's history, and git rebase main picks up the fresh base.

The destination doesn't have to exist yet, and it doesn't have to match
the source's name:

$ git fetch origin main:hotfix-base
From …/origin
 * [new branch]      main       -> hotfix-base

A single fetch also takes as many refspecs as you care to give it, so
several branches can come current in one trip.

The remote is optional

If a plain git fetch origin has already run (your hand, your editor, a
background sync), the new commits are sitting in your repository with
only the tracking ref pointing at them, and your local branch is the one
thing still stale. No second network trip needed: a repository
can fetch from itself.

$ git fetch origin
From …/origin
   114c7a5..c21574c  main       -> origin/main
$ git fetch . origin/main:main
From .
   114c7a5..c21574c  origin/main -> main
$ git log --oneline -1 main
c21574c Add tests (#14)

. is the repository you're in, treated as its own remote. The first
command moved the tracking ref over the network; the second copied it
onto the branch without any. The ref update is the same either way, so
everything that follows (the refusals, the fast-forward rule) applies to
a fetch from . exactly as it does to one from origin.

The branch you're standing on is off limits

The exception is the branch that's checked out. Switch to main and
try to update it the same way:

$ git fetch origin main:main
fatal: refusing to fetch into branch 'refs/heads/main' checked out at '…/repo'

Note the fatal: this aborts the whole fetch before anything transfers,
tracking ref included.

The refusal protects an agreement. A checkout is three things in
sync: the branch ref, the index, and the working tree. Fetch moves refs
and reconciles nothing, so aiming it at the checked-out branch would
move one of the three and leave the other two describing a commit that
is no longer HEAD. There's a flag that overrides the refusal, and it
makes a tidy demonstration of why you shouldn't:

$ git fetch --update-head-ok origin main:main   # demo only — clean tree required
From …/origin
   c21574c..0538f6b  main       -> main
   c21574c..0538f6b  main       -> origin/main
$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    deleted:    docs.md

That is a staged deletion you never made. The fetched commit added
docs.md; your index still describes the tree from before it;
git status reports the difference as your doing. Commit from here
and you revert the change you just pulled. Provided the working tree
is clean, git reset --hard puts the three back in agreement by
rebuilding the index and working tree to match the moved branch; with
uncommitted work present it would destroy that work too. Then
git switch - back to feature.

The flag exists for git pull, which passes it on every fetch it runs.
A stock pull doesn't need it: its fetch half only writes origin/*, and
the merge or rebase half is what moves your branch. But a pull carrying
a refspec (git pull origin main:main, for instance) does fetch
straight into the checked-out branch. What makes that safe is that pull
reconciles the index and working tree immediately afterward (its output
even says "fast-forwarding your working tree"); that reconciliation is
the step --update-head-ok alone skips.

The same refusal covers a branch checked out anywhere. If main lives
in a linked worktree, fetching into it fails from the primary checkout
too, and the message names the path holding it:

$ git worktree add ../wt-main main
Preparing worktree (checking out 'main')
HEAD is now at 0538f6b Add docs (#15)
$ git fetch origin main:main
fatal: refusing to fetch into branch 'refs/heads/main' checked out at '…/wt-main'
$ git worktree remove ../wt-main

Nor is the refusal a quirk of fetch: git branch -f declines to move a
checked-out branch with the same reasoning. For an idle branch, though,
the two are not interchangeable. branch -f repoints the ref wherever
you say, no questions asked; the refspec holds the fast-forward line
you're about to meet. And for the branch you're on, the updater is
the one you already know, git pull, for exactly the
reconciliation reason above.

When the branch has commits of its own

A fast-forward is the only move a plain refspec will make. If main has
a commit the remote doesn't, because you committed to it by accident or
you're carrying a local patch, the update is rejected:

$ git log --oneline -1 main
c540dc1 wip: note to self
$ git rev-parse --short origin/main
0538f6b
$ git fetch origin main:main
From …/origin
 ! [rejected]        main       -> main  (non-fast-forward)
   0538f6b..62fb195  main       -> origin/main
$ git rev-parse --short origin/main
0538f6b

A fast-forward discards nothing; anything else could. It's the same
conservatism as the checkout refusal, applied to history instead of
the working tree.

Look at the two rev-parse calls, though. The ! [rejected] line is
truthful; the origin/main line under it never took effect — the ref
reads 0538f6b before and after, whatever the output says about
62fb195. On the Git these transcripts ran on (2.51), a rejected
refspec takes the opportunistic tracking update down with it. The
manual doesn't specify which way this goes, so another version may keep
the tracking update; the habit that holds everywhere is to let
rev-parse tell you what moved after any rejection, and to run a plain
git fetch origin if you want the tracking ref current.

You can insist. A leading + on the refspec (or --force)
permits the non-fast-forward:

$ git fetch origin +main:main
From …/origin
 + c540dc1...62fb195 main       -> main  (forced update)
   0538f6b..62fb195  main       -> origin/main
$ git log --oneline -1 'main@{1}'
c540dc1 wip: note to self

Notice the tracking line finally sticking: it's the same
0538f6b..62fb195 the rejection printed and canceled. And notice what
the force is: a reset wearing fetch's clothing. main now matches the
remote, and your local commit is off the branch — not destroyed,
main@{1} still names it, but off the branch, silently. If the stray
commit should keep a real name rather than a reflog entry, park it
before the force: git branch rescue main, then the forced fetch, and
afterward rescue points at your commit while main matches the remote.

If instead you meant to keep both sides on main, you want a merge or
a rebase, and those need a working tree. Any working tree satisfies
them, including one that exists for thirty seconds. Say the local
commit is deliberate this time, and the remote has moved again:

$ git fetch origin
From …/origin
   62fb195..5a013dc  main       -> origin/main
$ git log --oneline -1 main
687bfb7 fix: local-only patch
$ git worktree add ../tmp main
Preparing worktree (checking out 'main')
HEAD is now at 687bfb7 fix: local-only patch
$ git -C ../tmp merge --no-edit origin/main
Merge made by the 'ort' strategy.
 release.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 release.md
$ git worktree remove ../tmp
$ git log --oneline -2 main
a0ffdc9 Merge remote-tracking branch 'origin/main'
687bfb7 fix: local-only patch

Your own checkout never blinked. For the rebase preference,
git -C ../tmp rebase origin/main would have served the same way. Two
things about where this leaves you: main now carries a commit the
remote lacks, so the next plain main:main fetch is a rejection until
you push; and whether a merge like this one will conflict is
answerable before you run it,
from the same seat.

Or don't do any of this

The feature this post has been circling ships in GitDesktop,
the Git client I work on. After a fetch, every branch row shows how far
it sits ahead or behind its upstream, and a branch with commits to pull
offers Update from origin/… in its context menu: no switching, your
checkout stays put. Under that item, in order: an ancestry check to
classify the case, then git fetch . origin/main:main when it's a
fast-forward, and for a diverged branch the throwaway-worktree merge
from above — created, merged, removed, a conflicted merge aborted so
the branch is left exactly as it was. Aimed at the branch you're
standing on, it does the one reasonable thing left and merges in place,
conflicts and all, the way a plain pull would.

A branch is a name for a commit, and a name can move without you
standing on it. You check out a branch to work on it; updating it never
required your presence.

Will this merge conflict? Find out without merging

Evan — Mon, 31 Aug 2026 14:00:00 +0000

You're about to merge a long-running branch and you'd like to know, first,
whether it's going to hurt. Not "did it hurt" — will it. Ten files or two
hundred, five minutes or an afternoon, safe to do now or better after lunch.

Git has known the answer the whole time. It just isn't the answer you get from
running git merge and reading the wreckage.

The usual answer costs you your working tree

The standard trick is to merge without committing and look:

$ git merge --no-commit --no-ff feature
Auto-merging shared.txt
CONFLICT (content): Merge conflict in shared.txt
Automatic merge failed; fix conflicts and then commit the result.

That did tell you. It also rewrote your working tree to tell you:

$ git status --porcelain
UU shared.txt

Now you're sitting in a conflicted merge state you didn't want, and you have to
back out of it:

$ git merge --abort

For a one-file toy repo that's a nuisance. On a real branch it's worse than a
nuisance, because a branch hasn't been just a branch for years now. Touching the
working tree restarts dev servers, invalidates caches, triggers file watchers,
and re-runs whatever your editor does on change. You asked a question and paid
for it with your environment — the exact tax I built this client to
stop.

And if you're merging into a branch you don't have checked out, this approach
doesn't even apply. You'd have to check it out first.

Git will do the merge in memory instead

Since version 2.38, git merge-tree can perform a complete, real merge
(rename detection, the works) and write the result to the object database
without going near your working tree, your index, or HEAD:

$ git merge-tree --write-tree --name-only main feature
c9cc90770ebb9dee14e212f168dd40059cfb605a
shared.txt

Auto-merging shared.txt
CONFLICT (content): Merge conflict in shared.txt

The exit code is the verdict:

Exit	Meaning
`0`	Clean. The merge will succeed.
`1`	Conflict — or Git declined the merge outright.
other	Git couldn't start at all (unrelated histories exits `128`).

When the merge runs at all, line one is the OID of the merged tree. On a
conflict, the lines after it are the conflicted paths, then a blank line, then
the human-readable messages. On a clean merge you get line one and nothing else.
Here it runs against a sidebranch that diverged before main's edit and only
adds a file main has never seen:

$ git merge-tree --write-tree --name-only main sidebranch
bab3bcfcd19b35a6ecb2881d1602cf080e1cb547
$ echo $?
0

Which leaves that qualifier on exit 1. It does not mean "conflict" by
itself. Ask to merge a branch that doesn't exist and you get 1 as well, with a
completely empty stdout and the message going to stderr instead. So test stdout,
not the code alone: empty output means Git refused, which is "unknown", not "a
conflict in zero files".

Exit 0 is broad in its own way, which matters if you're building on this: it
covers a real three-way merge, a plain fast-forward, and an already-up-to-date
branch alike. merge-tree doesn't distinguish them, so if those mean different
things in your interface, you need a merge-base check alongside it.

And your working tree never moved:

$ git status --porcelain
$ git rev-parse --abbrev-ref HEAD
main

It's so thoroughly detached from your checkout that it runs fine in a bare repo,
which has no working tree to touch in the first place. That's the property that
makes it useful for a tool: you can preview merging any branch into any
other, without either one being checked out.

The merged tree is a real object

That OID isn't just an identifier for the answer — it's a tree in your object
database, and every read-only command that takes a tree will take it.

Want to see what the conflict actually looks like before deciding? Read the file
straight out of the merge result — conflict markers and all:

$ TREE=$(git merge-tree --write-tree --name-only main feature | head -1)
$ git cat-file -p "$TREE:shared.txt"
line1
<<<<<<< main
MAIN
=======
FEATURE
>>>>>>> feature
line3

Want the diffstat of what merging would do to you?

$ git diff --stat main "$TREE"
 shared.txt | 4 ++++
 1 file changed, 4 insertions(+)

Read that stat carefully, though: on a content conflict like this one the tree
holds the marked-up file, so the count includes the conflict markers themselves.
With the default conflict style, three of those four added lines are the
<<<<<<<, ======= and >>>>>>> you saw in the cat-file output — not work
you have to do. Set merge.conflictStyle to diff3 or zdiff3 and the same
merge reports six, because each conflict also carries a ||||||| section
and the base text.

Structural conflicts, where the sides disagree about whether a file exists or
where it lives (more on those below), vary more, so don't apply that
subtraction blindly. A modify/delete leaves one side's file whole with no
markers at all, and its stat is pure real change. But a rename/rename where
both sides also edited the file writes markers into both paths, so the
count inflates there too, and a file/directory clash reports a rename to a
mangled path rather than a file you recognize. Treat the stat as a rough
gauge, not an audit.

Even with those caveats you know the rough size of the job, which files are
involved, and, for the content conflicts, the exact shape of each one. All
without running a merge.

The trap: `-X ours` does less than you think

Now for the part that will lie to you if you build on it.

If a preview says "conflict", the obvious next thought is: fine, I'll merge with
a strategy option and let Git pick a side. So you re-run the preview mentally,
decide -X ours will mop it up, and report "3 conflicts, all auto-resolvable".

Sometimes that's true. -X ours really does resolve the content conflict above:

$ git merge-tree --write-tree --name-only -X ours main feature
51c500ddf270e2f1f6bdf80e5af7fb598c95910b
$ echo $?
0

Clean. Different tree, no conflicts, exit 0.

Now the same experiment where feature edited a file that main deleted:

$ git merge-tree --write-tree --name-only main feature
61eb2660b922022a67457fa4d76a1687b447e0ee
doomed.txt

CONFLICT (modify/delete): doomed.txt deleted in main and modified in feature.

$ git merge-tree --write-tree --name-only -X ours main feature
61eb2660b922022a67457fa4d76a1687b447e0ee
doomed.txt

CONFLICT (modify/delete): doomed.txt deleted in main and modified in feature.

Look at the tree OIDs. They're identical. -X ours didn't resolve it, didn't
change the outcome, didn't change a single byte of the result. -X theirs
produces that same OID too.

The reason is that -X ours and -X theirs only arbitrate content
conflicts — cases where one path ends up with two candidate texts and Git
needs only to be told which one wins. They have nothing to say about
structural ones, where the disagreement is about whether the file should
exist, or where it lives:

modify/delete — one side edited it, the other removed it
rename/delete — one side moved it, the other deleted it
rename/rename — one file moved to two different names
file/directory — one side made it a file, the other a directory

Git cannot pick a side there, because there is no "side" to pick; the question
isn't which text wins, it's what the tree should contain. Those stop the merge
no matter which -X you pass.

Don't sort by whether it looks structural, though; sort by whether there are two
texts to choose between. add/add looks structural, but both sides did produce
a file at one path, so there is a text to pick, and -X ours resolves it to
exit 0. When in doubt, run the specific case; the category name is a poor guide.

So if you're predicting the result of a merge that will use a strategy option,
re-run merge-tree with that option and report what it actually says.
Taking a no-strategy conflict list and relabeling it "will auto-resolve" is
wrong for exactly the conflicts a person most needs warning about.

What it costs

"Touches nothing" is a slight overstatement — in two ways.

It writes objects. --write-tree means what it says: the merged tree and any
merged blobs get written to the object database. How many depends on the merge.
Back in the throwaway shared.txt repo from earlier, clear the loose-object
count to zero so what follows is a clean delta. Do that only in a throwaway
repo: git gc --prune=now discards unreachable objects for good, including
stashes you could otherwise still recover.
With a clean baseline, the content conflict adds two — a tree, and the blob
holding the marked-up file:

$ git gc --prune=now      # throwaway repos only — destroys unreachable objects
$ git count-objects -v | grep '^count:'
count: 0
$ git merge-tree --write-tree --name-only main feature >/dev/null
$ git count-objects -v | grep '^count:'
count: 2

Run the same thing in the doomed.txt repo and the count doesn't move at all.
That merge's tree is byte-identical to one Git already had, so there is
nothing new to write.

The objects that do get written are unreachable the moment they land — but
"unreachable" is not "gone". git gc will not delete them: gc.pruneExpire
defaults to two weeks, so an ordinary gc sweeps them into a cruft pack instead.
The loose count falls back to zero while git cat-file -t <oid> still
cheerfully answers tree — so on a current Git the count-objects snippet
above will tell you they have vanished when they have not. (Before 2.41, when
cruft packs became the default, they simply stayed loose and the count stayed
at two.) Only git gc --prune=now actually removes them. The cost is real but
small, and it does clear itself — on Git's schedule, not on yours.

It needs a reasonably current Git. Both --write-tree and --name-only
arrived in Git 2.38, released on 2 October 2022. On anything older, the only
merge-tree you get is the one the manual now files under "DEPRECATED
DESCRIPTION" — a trivial merge that, in its own words, cannot "handle content
merges of individual files, rename detection, proper directory/file conflict
handling, etc."

That mode is still reachable today as --trivial-merge, and you don't want it:
it exits 0 even when it reports a conflict. A tool that shells out without
checking the version doesn't get an error on old Git — it gets a confidently
clean answer about a merge that will not be clean. Check the version, and
degrade to showing nothing rather than showing something wrong.

Or don't do any of this

You can see the pitch coming (I make one of these clients), so here
it is, plainly.

None of this is wasted knowledge. Knowing that Git will merge in memory for
free, and that -X ours can't rescue a modify/delete, makes you harder to
surprise. But it's also a shell pipeline you have to remember, at the
exact moment you're trying to decide something else.

In GitDesktop a merge-base check runs before the merge button
does anything, and that same merge-tree call runs when it's needed: already up
to date, fast-forward, clean, or conflicted with the file list already on screen
— and if you change the on-conflict strategy, the preview re-runs with that
strategy instead of guessing on your behalf. It's the same plumbing this post
just walked through, minus the remembering.

Shell or client, the point is the same: the answer was always available. A
merge is not the only way to find out what a merge would do.

Recovering a dropped stash: what git fsck can still find

Evan — Tue, 25 Aug 2026 16:20:06 +0000

You stashed something, moved on, and now it's gone. Maybe you ran git stash drop one too many times. Maybe a rebase went sideways and took the stash list
with it. Maybe you ran git stash pop into a conflict, cleaned up, and
dropped the entry before noticing the resolution was wrong.

The good news is that Git almost never deletes anything on the spot. A dropped
stash is unlinked, not erased, and it stays in the object database until garbage
collection decides otherwise. Here's how to get it back.

A stash is just commits

This is the part that makes the recovery make sense. git stash push doesn't
write to a special sidecar file — it creates real commits and points a ref at
them. Two commits, in the normal case:

$ git stash push -m "wip: the thing I care about"
Saved working directory and index state On main: wip: the thing I care about

Look at what that actually produced:

$ git log --format='%h  parents=%p  %s' --all --reflog
45199d0  parents=61bfbab 813b9d5  On main: wip: the thing I care about
813b9d5  parents=61bfbab            index on main: 61bfbab init
61bfbab  parents=                   init

The index on main commit holds what was staged. The On main: commit holds
the working tree, and it has two parents: the commit you were sitting on,
and that index commit. stash@{0} is just a ref pointing at the second one.

git stash drop deletes the ref. The commits are untouched. They're simply
unreachable now — nothing points to them, so nothing walks to them.

Finding it again

git fsck walks the object database and reports anything nothing else points
at:

$ git fsck --unreachable | grep commit
unreachable commit 813b9d5fb7fef45cc200e7b0f10e5a1e60714c1d
unreachable commit 45199d06525ecbd5658491c9b02a04f73ebbac64

Two hits for one stash — which is exactly where most recovery instructions leave
you guessing. They are not interchangeable. Apply the wrong one and you get only
what happened to be staged at the time, which can look convincingly like your
work while quietly missing most of it.

The stash commit is the one with two parents. You can read that straight off the
object:

$ git cat-file -p 45199d06 | grep '^parent'
parent 61bfbab...
parent 813b9d5...

Or let the shell pick it for you:

git fsck --unreachable | grep commit | awk '{print $3}' |
  while read sha; do
    [ "$(git cat-file -p "$sha" | grep -c '^parent')" -ge 2 ] &&
      echo "$sha  $(git log -1 --format='%s' "$sha")"
  done

That prints only real stash commits, each with the message you wrote — which is
usually enough to recognize the one you want.

Getting the work back

Once you have the SHA, git stash apply takes it directly. No ref required:

$ git stash apply 45199d06525ecbd5658491c9b02a04f73ebbac64
On branch main
Changes not staged for commit:
    modified:   a.txt

Your changes are back in the working tree.

If you'd rather look before you leap, inspect it first — a stash commit diffs
against its first parent like anything else:

git show 45199d06                # the working-tree changes
git show 45199d06^2              # what was staged at stash time

And if you want it back in the stash list as a proper entry rather than applied
straight to your tree:

git stash store -m "recovered" 45199d06

The catch

This works because the objects are still there, and that isn't forever. git gc
prunes unreachable objects once they age past gc.pruneExpire, which defaults to
two weeks. Garbage collection also runs automatically — git gc --auto fires
during ordinary commands once enough loose objects pile up.

So: a stash you dropped this morning is almost certainly recoverable. One from
last quarter probably isn't. If you've just realized something important is
missing, do the fsck now and don't run git gc first.

One thing that will not help: git reflog. The stash has its own reflog at
refs/stash, and dropping the stash takes that with it. The plain git reflog
only covers HEAD.

Or don't do any of this

This is where I mention that I make a Git client. Everything above is a
recipe I'd rather nobody had to run under pressure. Knowing that a stash is two
commits and that the real one has two parents is useful; I'd teach it to
anyone. But at the moment you actually need it, you're stressed, you're
guessing at SHAs, and the failure mode is silently restoring the wrong half
of your work.

In GitDesktop that same fsck walk runs behind a list:
recoverable stashes, each with its message, its date, and a diff you can read
before you commit to anything. Same objects, same operation, minus the shell
pipeline and minus the chance of applying the index twin by mistake.

Either way, remember the part that surprises people: it's still there. Git is
much more reluctant to destroy your work than it looks.

The Whole Loop, One Window

Evan — Mon, 17 Aug 2026 23:22:13 +0000

I've spent years working with Git.

Not just using it, but living in it. Feature branches, code reviews, releases, hotfixes, open source, side projects, client work—the rhythm becomes second nature.

And yet, over time, I noticed something strange.

The moment I needed to do anything beyond committing code, I was expected to leave.

Leave the Git client to create a pull request.

Leave it to review changes.

Leave it to check project traffic.

Leave it to manage branches.

Leave it to use AI.

Leave it to enforce the kinds of guardrails that prevent simple mistakes.

It never felt intentional. It was just... accepted.

But the more I thought about it, the more one question kept coming back:

Why am I leaving?

That question became GitDesktop.

When I first started planning the project, I wasn't trying to build a better GitHub Desktop.

I wasn't trying to cram every Git feature imaginable into one application.

The original idea was much simpler.

I wanted to build a calm Git client I could leave open all day.

Somewhere along the way, that idea became five words that ended up guiding every feature I built:

The whole loop, one window.

It wasn't a tagline.

It was a design constraint.

Every time I wanted to add something, I asked the same question:

Does this help me stay in the flow, or does it send me somewhere else?

Pull Requests shouldn't begin after you push
One of the biggest workflow interruptions for me has always been creating pull requests.

The workflow looked something like this:

Stage changes.

Commit.

Open GitHub.

Create a pull request.

Write the title.

Write the description.

Maybe ask AI to help.

Everything about that process felt disconnected.

The repository was already on my machine.

The diffs were already on my machine.

The commit history was already on my machine.

So why did the workflow suddenly move into a browser?

When GitHub introduced Copilot-powered pull request generation, I actually thought it was a great feature.

But I already preferred Claude.

I didn't want to switch assistants depending on where I happened to be working.

I wanted the workflow—not the provider.

That eventually led to one of my favorite features in GitDesktop: Local Pull Requests.

Not because they're technically interesting.

Because they challenge an assumption I don't think we've questioned enough.

We tend to think a pull request begins the moment we push.

I don't.

To me, pushing is the moment a pull request graduates from private work to shared work.

Before that, I'm still thinking.

I'm still iterating.

I'm still rewriting descriptions.

I'm still asking AI to review something.

I'm still cleaning up commits.

I'm still deciding whether it's ready for someone else's time.

Why should any of that require a remote repository?

GitDesktop lets me prepare the entire review locally before deciding to publish it.

Not because GitHub can't review code.

Because I believe the first reviewer should always be yourself.

Branches are no longer just branches
Years ago, switching branches was almost free.

Today, a branch is an environment.

Switching branches can restart development servers.

Hot module replacement kicks in.

Dependencies change.

Generated files change.

Environment variables change.

Migrations change.

I've had moments where I switched back to an old feature branch just to update it and suddenly found hundreds of files appearing as untracked because .gitignore had changed on another branch.

Not because I intended to work there.

Simply because Git required me to visit that branch before updating it.

Another time, I interrupted active development just to pull changes into a long-running epic.

Everything restarted.

The application reloaded.

The context I was in disappeared.

None of that had anything to do with the work I was actually trying to accomplish.

I just wanted to bring another branch up to date.

So GitDesktop lets me do exactly that.

Update another branch without leaving the one I'm currently working in.

Not because it's impossible otherwise.

Because switching contexts should be a choice—not a requirement.

Guardrails shouldn't be a pricing tier
Some of my favorite GitDesktop features exist because of incredibly ordinary mistakes.

I've merge committed directly into development branches because muscle memory took over.

I've deleted the wrong branch after promoting a release.

None of these were knowledge problems.

They were human problems.

GitHub has branch protections.

They're great.

But many of the protections I wanted either happen remotely or are tied to higher-tier workflows.

That always felt backwards.

The best safety features shouldn't only exist after you've already pushed your code somewhere.

They shouldn't only exist for large organizations.

Sometimes you just want your tools to stop you from making an obvious mistake.

Local branch protection came from that belief.

Good guardrails should be available wherever you're working.

Especially when you're working alone.

Monitoring shouldn't require hunting
Another habit I've developed over the years is checking on my projects.

Not because I enjoy dashboards.

Because I genuinely like seeing whether people are using the things I've built.

How many visitors showed up today?

Where did they come from?

Which repositories are getting attention?

That routine usually meant opening GitHub...

Then another repository.

Then another.

Eventually I had several browser tabs open just to answer one simple question:

How are my projects doing?

It felt disconnected.

The repositories I cared about were already sitting inside the Git client I had open all day.

Why wasn't that information there too?

Repository Insights wasn't born out of wanting prettier graphs.

It was born out of wanting the projects I care about to stay close.

Bring your own workflow
AI accelerated this realization.

Every company wants you inside their ecosystem.

Use their assistant.

Use their models.

Use their workflow.

But developers don't work that way.

Some people prefer Claude.

Some use OpenAI.

Others run local models.

Tomorrow there will be something new.

The tool shouldn't force that decision.

It should adapt to it.

The same applies beyond AI.

Whether it's GitHub, GitLab, Bitbucket, or something else, I don't think your development workflow should be dictated by whichever platform happens to host your repository.

Your tools should work with you.

Not the other way around.

Questioning assumptions
As I look back over GitDesktop, I notice something.

I wasn't really building features.

I was questioning assumptions.

Why does a pull request require a remote?

Why do reviews begin after pushing?

Why do I have to leave my Git client to understand my project?

Why should switching AI models change my workflow?

Why should updating another branch interrupt the one I'm actively working in?

Why are some of the best guardrails only available after code leaves my machine?

Every feature traces back to one of those questions.

The whole loop, one window
If GitHub Desktop adopted every feature I've built tomorrow, I'd be thrilled for developers.

But I don't think we'd be building the same product.

Because GitDesktop isn't defined by Local Pull Requests, branch protection, AI integration, or repository insights.

It's defined by a philosophy.

I believe developer tools should adapt to developers—not ask developers to adapt to them.

I believe the best workflows happen as close to the code as possible.

And I believe every unnecessary context switch is an opportunity to ask a simple question:

Do I actually need to leave?

That question has shaped every feature in GitDesktop so far.

And I suspect it'll shape every feature I build next.

Because for me, the goal has never been to build another Git client.

It's been to build the one I never have to leave.

What's one part of your workflow that always makes you think, "Why do I have to leave?"

This essay also lives on the GitDesktop blog — https://gitdesktop.app/blog/the-whole-loop-one-window/

DEV Community: Evan

git pull --rebase deleted your commit: the rescue and the reason

Two clones, one branch

The force push you never saw

The pull

The rescue

Why the rebase threw it away

The flag that doesn't exist

Integrating it properly

Or don't do any of this

Work on two branches at once with git worktree

A second folder, same repository

The fix, without the dance

One branch, one checkout

The stash is shared too

Folders are disposable, the bookkeeping isn't

Or don't do any of this

Update a Git branch without checking it out

The colon in the refspec

The remote is optional

The branch you're standing on is off limits

When the branch has commits of its own

Or don't do any of this

Will this merge conflict? Find out without merging

The usual answer costs you your working tree

Git will do the merge in memory instead

The merged tree is a real object

The trap: -X ours does less than you think

What it costs

Or don't do any of this

Recovering a dropped stash: what git fsck can still find

A stash is just commits

Finding it again

Getting the work back

The catch

Or don't do any of this

The Whole Loop, One Window

The trap: `-X ours` does less than you think