Re: Difficulties using git rebase. Help, please!

Re: Difficulties using git rebase. Help, please!

[Alan Mackenzie]

On Sun, Jan 11, 2026 at 15:33:51 +0000, Alan Mackenzie wrote:
> Hello, Git.

> Some while ago I made some amendments to the Linux kernel for my own use
> (at least).  I now want to rebase these changes onto the master branch of
> the Linux Stable repository.

[ .... ]

Sorry, I forgot to mention I'm using git version 2.52.0.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulties using git rebase. Help, please!

[Pushkar Singh]

Hi Alan,

What you are seeing is consistent with Git believing that your branch
contains about 2012 commits on
top of origin/linux-6.13.y. That does not mean you personally wrote
2012 commits. It means your branch
is based on a moving remote branch instead of on a fixed base commit.

When you run:
    git rebase --onto master origin/linux-6.13.y HEAD

Git takes everything that is reachable from HEAD but not reachable
from origin/linux-6.13.y and tries to
replay it on top of master. Since origin/linux-6.13.y has moved
forward over time, that set likely includes
a large part of the stable kernel history, not just your own changes.
That explains why you are seeing
conflicts in files you never touched.

This also matches what git status reports:
    Your branch is ahead of 'origin/linux-6.13.y' by 2012 commits.

Those 2012 commits are not yours; they are the commits that
accumulated on the linux-6.13.y branch
since you originally branched from it.

What you usually want is to rebase only the commits you authored. To
do that, you need to find the commit
where your work originally forked from linux-6.13.y, for example:
    base=$(git merge-base HEAD origin/linux-6.13.y)
    git rebase --onto master $base

This tells Git to replay only the commits after that fork point, which
should be just your patches.

Regarding previewing what will be rebased, there is not a simple "how
many conflicts" dry run, but git range-diff
is very useful to see what would be moved:
    git range-diff $base..HEAD master

That shows exactly which commits would be replayed and how they would
compare after rebasing.

I hope this clarifies why you saw those conflicts and helps you move forward.

Best,
Pushkar

On Sun, Jan 11, 2026 at 9:25 PM Alan Mackenzie <acm@muc.de> wrote:
>
> On Sun, Jan 11, 2026 at 15:33:51 +0000, Alan Mackenzie wrote:
> > Hello, Git.
>
> > Some while ago I made some amendments to the Linux kernel for my own use
> > (at least).  I now want to rebase these changes onto the master branch of
> > the Linux Stable repository.
>
> [ .... ]
>
> Sorry, I forgot to mention I'm using git version 2.52.0.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

Difficulties using git rebase. Help, please!

[Alan Mackenzie]

Hello, Git.

Some while ago I made some amendments to the Linux kernel for my own use
(at least).  I now want to rebase these changes onto the master branch of
the Linux Stable repository.

When I wrote the changes, I based them off branch linux-6.13.y.  The
command I tried to rebase with was, with PWD being the pertinent copy of
the Linux repository:

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

Incidentally, when I do git status, I get as part of the output:

    Your branch is ahead of 'origin/linux-6.13.y' by 2012 commits.

..  I haven't done 2012 git commits in my life.  What does this number
2012 mean?

So, back to git rebase.  Would somebody please explain why I am seeing
these conflicts at all?  Please also help me make progress.  I'm stuck.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulties using git rebase. Help, please!

[Alan Mackenzie]

Hello again, Git.

On Sun, Jan 11, 2026 at 15:46:13 +0000, Alan Mackenzie wrote:
> Hello, Git.

> Some while ago I made some amendments to the Linux kernel for my own use
> (at least).  I now want to rebase these changes onto the master branch of
> the Linux Stable repository.

> When I wrote the changes, I based them off branch linux-6.13.y.  The
> command I tried to rebase with was, with PWD being the pertinent copy of
> the Linux repository:

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

> Incidentally, when I do git status, I get as part of the output:

>     Your branch is ahead of 'origin/linux-6.13.y' by 2012 commits.

> ..  I haven't done 2012 git commits in my life.  What does this number
> 2012 mean?

> So, back to git rebase.  Would somebody please explain why I am seeing
> these conflicts at all?  Please also help me make progress.  I'm stuck.

> Thanks!

I've had a most helpful reply by private email that suggested I try:

    git log --oneline origin/linux-6.13.y..HEAD | wc -l

..  This gave 2012, the number of commits git status says I'm ahead of
that branch by.

On removing the | wc -l from the command line, I see all these 2012
commits summarised.  It turns out, just the top eight were mine,
followed by

    733381204a86 Linux 6.13.3-rc1

..  So if I delimit the commits to apply using 733381204a86 rather than
origin/linux-6.13.y, the rebasing should work.  So I tried:

    $ git rebase --onto master 733381204a86 HEAD

, which now gives me conflicts just in my own commits.  Success!  I now
have the arduous task of resolving all these conflicts.  The diff I'm
working with is around 3400 lines long.  ;-(

So many thanks to my helper.  Why don't you say who you are and collect
the credit you seem to be due?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulties using git rebase. Help, please!

[Kristoffer Haugsbakk]

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.


>[snip]

Re: Difficulties using git rebase. Help, please!

[Jeff King]

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

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

Re: Difficulties using git rebase. Help, please!

[Pushkar Singh]

Hi Alan,

That was me. Glad it helped, and I am happy you got the rebase working.

Rebasing against the merge base instead of the moving
origin/linux-6.13.y branch avoids pulling in all the upstream
stable commits.

Best,
Pushkar

On Tue, Jan 13, 2026 at 10:41 PM Jeff King <peff@peff.net> wrote:
>
> On Mon, Jan 12, 2026 at 05:08:52PM +0100, Kristoffer Haugsbakk wrote:
>
> > 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.
>