DEV Community: Evan

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

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