{"thread":{"id":"64772","subject":"Difficulties using git rebase. Help, please!","startedAt":"2026-01-11T15:46:16Z","lastAt":"2026-01-13T17:41:14Z","messageCount":5,"participants":["Alan Mackenzie","Kristoffer Haugsbakk","Jeff King","Pushkar Singh"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"533529","messageId":"aWPFxQloyfx8x0ED@MAC.fritz.box","threadId":"64772","inReplyTo":null,"subject":"Difficulties using git rebase. Help, please!","fromName":"Alan Mackenzie","fromEmail":"acm@muc.de","sentAt":"2026-01-11T15:46:13Z","receivedAt":"2026-01-11T15:46:16Z","isPatch":false,"sender":{"key":"acm@muc.de","avatar":null},"body":"Hello, Git.\n\nSome while ago I made some amendments to the Linux kernel for my own use\n(at least).  I now want to rebase these changes onto the master branch of\nthe Linux Stable repository.\n\nWhen I wrote the changes, I based them off branch linux-6.13.y.  The\ncommand I tried to rebase with was, with PWD being the pertinent copy of\nthe Linux repository:\n\n    $ git rebase --onto master origin/linux-6.13.y HEAD\n\n..  This didn't work well.  In particular, I got a conflict in a file that\nI had never changed.  Why?\n\nWell, I corrected the conflicts in that file, git add'ed it, git rebase\n--continue'd, then got another conflict in a file I'd never touched.\nSame again.  After the third such conflict, I gave up with git rebase\n--abort.\n\nCriticism: there doesn't appear to be a --dry-run option in git rebase,\nwith which one can see how many files will be conflicted.  Instead they\nare notified one at a time, drip, drip, drip, .... to the user.  In my\ncase there might have been four conflicted files, there might have been a\nthousand.  Either I'm missing something, or git rebase is missing\nsomething, hopefully the former.\n\nIncidentally, when I do git status, I get as part of the output:\n\n    Your branch is ahead of 'origin/linux-6.13.y' by 2012 commits.\n\n..  I haven't done 2012 git commits in my life.  What does this number\n2012 mean?\n\nSo, back to git rebase.  Would somebody please explain why I am seeing\nthese conflicts at all?  Please also help me make progress.  I'm stuck.\n\nThanks!\n\n-- \nAlan Mackenzie (Nuremberg, Germany).\n"},{"id":"533650","messageId":"aWUXGCI3fJc_Z4vp@MAC.fritz.box","threadId":"64772","inReplyTo":"aWPFxQloyfx8x0ED@MAC.fritz.box","subject":"Re: Difficulties using git rebase. Help, please!","fromName":"Alan Mackenzie","fromEmail":"acm@muc.de","sentAt":"2026-01-12T15:45:28Z","receivedAt":"2026-01-12T15:45:36Z","isPatch":false,"sender":{"key":"acm@muc.de","avatar":null},"body":"Hello again, Git.\n\nOn Sun, Jan 11, 2026 at 15:46:13 +0000, Alan Mackenzie wrote:\n> Hello, Git.\n\n> Some while ago I made some amendments to the Linux kernel for my own use\n> (at least).  I now want to rebase these changes onto the master branch of\n> the Linux Stable repository.\n\n> When I wrote the changes, I based them off branch linux-6.13.y.  The\n> command I tried to rebase with was, with PWD being the pertinent copy of\n> the Linux repository:\n\n>     $ git rebase --onto master origin/linux-6.13.y HEAD\n\n> ..  This didn't work well.  In particular, I got a conflict in a file that\n> I had never changed.  Why?\n\n> Well, I corrected the conflicts in that file, git add'ed it, git rebase\n> --continue'd, then got another conflict in a file I'd never touched.\n> Same again.  After the third such conflict, I gave up with git rebase\n> --abort.\n\n> Criticism: there doesn't appear to be a --dry-run option in git rebase,\n> with which one can see how many files will be conflicted.  Instead they\n> are notified one at a time, drip, drip, drip, .... to the user.  In my\n> case there might have been four conflicted files, there might have been a\n> thousand.  Either I'm missing something, or git rebase is missing\n> something, hopefully the former.\n\n> Incidentally, when I do git status, I get as part of the output:\n\n>     Your branch is ahead of 'origin/linux-6.13.y' by 2012 commits.\n\n> ..  I haven't done 2012 git commits in my life.  What does this number\n> 2012 mean?\n\n> So, back to git rebase.  Would somebody please explain why I am seeing\n> these conflicts at all?  Please also help me make progress.  I'm stuck.\n\n> Thanks!\n\nI've had a most helpful reply by private email that suggested I try:\n\n    git log --oneline origin/linux-6.13.y..HEAD | wc -l\n\n..  This gave 2012, the number of commits git status says I'm ahead of\nthat branch by.\n\nOn removing the | wc -l from the command line, I see all these 2012\ncommits summarised.  It turns out, just the top eight were mine,\nfollowed by\n\n    733381204a86 Linux 6.13.3-rc1\n\n..  So if I delimit the commits to apply using 733381204a86 rather than\norigin/linux-6.13.y, the rebasing should work.  So I tried:\n\n    $ git rebase --onto master 733381204a86 HEAD\n\n, which now gives me conflicts just in my own commits.  Success!  I now\nhave the arduous task of resolving all these conflicts.  The diff I'm\nworking with is around 3400 lines long.  ;-(\n\nSo many thanks to my helper.  Why don't you say who you are and collect\nthe credit you seem to be due?\n\n-- \nAlan Mackenzie (Nuremberg, Germany).\n"},{"id":"533652","messageId":"fefb3d25-3723-4e10-893a-620fbdc0cc45@app.fastmail.com","threadId":"64772","inReplyTo":"aWPFxQloyfx8x0ED@MAC.fritz.box","subject":"Re: Difficulties using git rebase. Help, please!","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-01-12T16:08:52Z","receivedAt":"2026-01-12T16:09:14Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Sun, Jan 11, 2026, at 16:46, Alan Mackenzie wrote:\n>[snip]\n>     $ git rebase --onto master origin/linux-6.13.y HEAD\n>\n> ..  This didn't work well.  In particular, I got a conflict in a file that\n> I had never changed.  Why?\n>\n> Well, I corrected the conflicts in that file, git add'ed it, git rebase\n> --continue'd, then got another conflict in a file I'd never touched.\n> Same again.  After the third such conflict, I gave up with git rebase\n> --abort.\n>\n> Criticism: there doesn't appear to be a --dry-run option in git rebase,\n> with which one can see how many files will be conflicted.  Instead they\n> are notified one at a time, drip, drip, drip, .... to the user.  In my\n> case there might have been four conflicted files, there might have been a\n> thousand.  Either I'm missing something, or git rebase is missing\n> something, hopefully the former.\n\nJust a dry-run? I would use `git merge-tree HEAD\norigin/linux-6.13.y`. Then you get to see what files are conflicted\nwithout stepping through anything.\n\n\n>[snip]\n"},{"id":"533755","messageId":"20260113171030.GB265671@coredump.intra.peff.net","threadId":"64772","inReplyTo":"fefb3d25-3723-4e10-893a-620fbdc0cc45@app.fastmail.com","subject":"Re: Difficulties using git rebase. Help, please!","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-01-13T17:10:30Z","receivedAt":"2026-01-13T17:10:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 12, 2026 at 05:08:52PM +0100, Kristoffer Haugsbakk wrote:\n\n> On Sun, Jan 11, 2026, at 16:46, Alan Mackenzie wrote:\n> >[snip]\n> >     $ git rebase --onto master origin/linux-6.13.y HEAD\n> >\n> > ..  This didn't work well.  In particular, I got a conflict in a file that\n> > I had never changed.  Why?\n> >\n> > Well, I corrected the conflicts in that file, git add'ed it, git rebase\n> > --continue'd, then got another conflict in a file I'd never touched.\n> > Same again.  After the third such conflict, I gave up with git rebase\n> > --abort.\n> >\n> > Criticism: there doesn't appear to be a --dry-run option in git rebase,\n> > with which one can see how many files will be conflicted.  Instead they\n> > are notified one at a time, drip, drip, drip, .... to the user.  In my\n> > case there might have been four conflicted files, there might have been a\n> > thousand.  Either I'm missing something, or git rebase is missing\n> > something, hopefully the former.\n> \n> Just a dry-run? I would use `git merge-tree HEAD\n> origin/linux-6.13.y`. Then you get to see what files are conflicted\n> without stepping through anything.\n\nMinor pedantry, but: those are not quite the same thing[1]. You may have\nconflicts in the rebase that would not be seen by merging the endpoints\n(in the simplest case, imagine a series which makes a change and then\nreverts it).\n\nI do think it's a good approximation, though. But that also points to\nwhy OP's request for a --dry-run can't be fulfilled: we can't know what\nconflicts we'll see in patch 2 until we know what the tree state is\nafter applying patch 1. If there are conflicts in patch 1, we don't know\nwhat that state is until the user resolves them.\n\n-Peff\n\n[1] If you want to dive into the world of rebase vs merge conflicts,\n    check out Michael Haggerty's imerge tool:\n\n      https://github.com/mhagger/git-imerge\n\n    and some of the associated blog posts and presentations. It can make\n    big ugly rebases/merges easier to deal with.\n"},{"id":"533760","messageId":"CALE2CrQ415Ewm_F-DLZu=JY2BTWofmGgorEOa0D=USr5d510SQ@mail.gmail.com","threadId":"64772","inReplyTo":"20260113171030.GB265671@coredump.intra.peff.net","subject":"Re: Difficulties using git rebase. Help, please!","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-01-13T17:41:02Z","receivedAt":"2026-01-13T17:41:14Z","isPatch":false,"sender":{"key":"pushkarkumarsingh1970@gmail.com","avatar":"https://avatars.githubusercontent.com/u/173247767?v=4"},"body":"Hi Alan,\n\nThat was me. Glad it helped, and I am happy you got the rebase working.\n\nRebasing against the merge base instead of the moving\norigin/linux-6.13.y branch avoids pulling in all the upstream\nstable commits.\n\nBest,\nPushkar\n\nOn Tue, Jan 13, 2026 at 10:41 PM Jeff King <peff@peff.net> wrote:\n>\n> On Mon, Jan 12, 2026 at 05:08:52PM +0100, Kristoffer Haugsbakk wrote:\n>\n> > On Sun, Jan 11, 2026, at 16:46, Alan Mackenzie wrote:\n> > >[snip]\n> > >     $ git rebase --onto master origin/linux-6.13.y HEAD\n> > >\n> > > ..  This didn't work well.  In particular, I got a conflict in a file that\n> > > I had never changed.  Why?\n> > >\n> > > Well, I corrected the conflicts in that file, git add'ed it, git rebase\n> > > --continue'd, then got another conflict in a file I'd never touched.\n> > > Same again.  After the third such conflict, I gave up with git rebase\n> > > --abort.\n> > >\n> > > Criticism: there doesn't appear to be a --dry-run option in git rebase,\n> > > with which one can see how many files will be conflicted.  Instead they\n> > > are notified one at a time, drip, drip, drip, .... to the user.  In my\n> > > case there might have been four conflicted files, there might have been a\n> > > thousand.  Either I'm missing something, or git rebase is missing\n> > > something, hopefully the former.\n> >\n> > Just a dry-run? I would use `git merge-tree HEAD\n> > origin/linux-6.13.y`. Then you get to see what files are conflicted\n> > without stepping through anything.\n>\n> Minor pedantry, but: those are not quite the same thing[1]. You may have\n> conflicts in the rebase that would not be seen by merging the endpoints\n> (in the simplest case, imagine a series which makes a change and then\n> reverts it).\n>\n> I do think it's a good approximation, though. But that also points to\n> why OP's request for a --dry-run can't be fulfilled: we can't know what\n> conflicts we'll see in patch 2 until we know what the tree state is\n> after applying patch 1. If there are conflicts in patch 1, we don't know\n> what that state is until the user resolves them.\n>\n> -Peff\n>\n> [1] If you want to dive into the world of rebase vs merge conflicts,\n>     check out Michael Haggerty's imerge tool:\n>\n>       https://github.com/mhagger/git-imerge\n>\n>     and some of the associated blog posts and presentations. It can make\n>     big ugly rebases/merges easier to deal with.\n>\n"}]}