Re: Difficulties using git rebase. Help, please!

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

On Sun, Jan 11, 2026, at 16:46, Alan Mackenzie wrote:

quoted

[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.