Re: [PATCH 0/2] rebase: add --fixup to fold a range into its oldest commit

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Jun 15, 2026, 15:17 UTC
Message-ID: <CALnO6CBgHz5d5BT5gCyqyhw_HpV733msWOnrxmu-TJ0QGHE9tA@mail.gmail.com>
In-Reply-To: <CAHwyqnWa55xbTpzq-Nf6cMyvgR1yYgg8fhvgMFkquSEGPUwDmg@mail.gmail.com>

On Mon, Jun 15, 2026 at 4:22 AM Harald Nordgren <haraldnordgren@gmail.com> wrote:

> > > Adds git rebase --autosquash --fixup [<upstream>] to fold a range of commits
> > > into its oldest one, reusing that commit's message.

[snip]

Show 12 quoted lines

> > I also wonder if we can do something like this without adding any
> > new option or command.  E.g., if you have four patch series, where
> > the initial implementation HEAD~3 is followed by "oops it was still
> > wrong" fix-up HEAD~2, HEAD~1 and HEAD, then
> >
> >     git reset --soft HEAD~3 && git commit --amend --no-edit
> >
> > is what the user wants to do, no?
>
> I don't think it's enough. First of all the user has to know the N for
> HEAD~N, and then 'git reset --soft HEAD~N && git commit --amend
> --no-edit' is still quite ugly.

Well, there are a few ways to get this more easily than counting; for example,

- git rev-list @{u}.. | tail -n1
- the lovely ":/<pattern>" or "@^{/<pattern>}" revision notations
- etc.

---

Stepping back a moment and assuming that the important thing you want is the "squash" (and not necessarily the "rebase" moving commits onto a new base), I wonder about

     git history squash <range>

which would squash all commits in the (now arbitrary!) range into the first. That makes it somewhat more versatile at selecting commits, I think, at the cost that re-basing is somewhat harder. That is, you could then do

    git history squash @~3..

and things like

    git history squash @~5..@~2

As a future extension, I think we could support merge commits: merges could be replayed as a merge into the final squash instead (creating an octopus merge if there are multiple merges to replay), though I'm hand-waving what we should do for conflicts. (We _do_ know what the final tree should look like—the same as the final commit in the range—so maybe we can actually avoid all conflicts?)

Anyway, I've cc'd Patrick for his opinion about whether this fits in "git-history".

-- 
D. Ben Knoble