threads / discuss / 64772

Difficulties using git rebase. Help, please!

Subject: Difficulties using git rebase. Help, please!

## tl;dr

5 messages between Jan 11, 2026 and Jan 13, 2026.

replies: 4people: 4as markdown or json

Alan Mackenzie· Jan 11, 2026, 15:46 UTC · lore

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

Alan Mackenzie· Jan 12, 2026, 15:45 UTC · re: Alan Mackenzie · lore

Re: Difficulties using git rebase. Help, please!

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.

Show 6 quoted lines

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

Kristoffer Haugsbakk· Jan 12, 2026, 16:08 UTC · re: Alan Mackenzie · lore

Re: Difficulties using git rebase. Help, please!

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

Show 17 quoted lines

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

Jeff King· Jan 13, 2026, 17:10 UTC · re: Kristoffer Haugsbakk · lore

Re: Difficulties using git rebase. Help, please!

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.

Pushkar Singh· Jan 13, 2026, 17:41 UTC · re: Jeff King · lore

Re: Difficulties using git rebase. Help, please!

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:

Show 47 quoted lines

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