Re: Difficulties using git rebase. Help, please!
- From
Pushkar Singh <pushkarkumarsingh1970@gmail.com>
- Date
- Jan 13, 2026, 17:41 UTC
- Message-ID
- <CALE2CrQ415Ewm_F-DLZu=JY2BTWofmGgorEOa0D=USr5d510SQ@mail.gmail.com>
- In-Reply-To
- <20260113171030.GB265671@coredump.intra.peff.net>
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. >