Re: Difficulties using git rebase. Help, please!

From: Jeff King <peff@peff.net>
Date: Jan 13, 2026, 17:10 UTC
Message-ID: <20260113171030.GB265671@coredump.intra.peff.net>
In-Reply-To: <fefb3d25-3723-4e10-893a-620fbdc0cc45@app.fastmail.com>

On Mon, Jan 12, 2026 at 05:08:52PM +0100, Kristoffer Haugsbakk wrote:

Show 22 quoted lines

> On Sun, Jan 11, 2026, at 16:46, Alan Mackenzie wrote:
> >[snip]
> >     $ git rebase --onto master origin/linux-6.13.y HEAD
> >
> > ..  This didn't work well.  In particular, I got a conflict in a file that
> > I had never changed.  Why?
> >
> > Well, I corrected the conflicts in that file, git add'ed it, git rebase
> > --continue'd, then got another conflict in a file I'd never touched.
> > Same again.  After the third such conflict, I gave up with git rebase
> > --abort.
> >
> > Criticism: there doesn't appear to be a --dry-run option in git rebase,
> > with which one can see how many files will be conflicted.  Instead they
> > are notified one at a time, drip, drip, drip, .... to the user.  In my
> > case there might have been four conflicted files, there might have been a
> > thousand.  Either I'm missing something, or git rebase is missing
> > something, hopefully the former.
> 
> Just a dry-run? I would use `git merge-tree HEAD
> origin/linux-6.13.y`. Then you get to see what files are conflicted
> without stepping through anything.

Minor pedantry, but: those are not quite the same thing[1]. You may have conflicts in the rebase that would not be seen by merging the endpoints (in the simplest case, imagine a series which makes a change and then reverts it).

I do think it's a good approximation, though. But that also points to why OP's request for a --dry-run can't be fulfilled: we can't know what conflicts we'll see in patch 2 until we know what the tree state is after applying patch 1. If there are conflicts in patch 1, we don't know what that state is until the user resolves them.

-Peff

[1] If you want to dive into the world of rebase vs merge conflicts,
    check out Michael Haggerty's imerge tool:

      https://github.com/mhagger/git-imerge

    and some of the associated blog posts and presentations. It can make
    big ugly rebases/merges easier to deal with.