Re: Difficulties using git rebase. Help, please!

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: