From: Patrick Steinhardt <ps@pks.im>
Date: Tue, 16 Jun 2026 08:34:07 GMT
Subject: Re: [PATCH 0/2] rebase: add --fixup to fold a range into its oldest commit
Message-ID: <ajEKf-jCIDVPQCeO@pks.im>
In-Reply-To: <CALnO6CBgHz5d5BT5gCyqyhw_HpV733msWOnrxmu-TJ0QGHE9tA@mail.gmail.com>

On Mon, Jun 15, 2026 at 11:17:21AM -0400, D. Ben Knoble wrote:
> 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]
> > > 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".

Yes, it does fit into git-history(1), and I do indeed already have plans
to implement such a command going forward. I wouldn't mind at all though
if somebody else beat me to it, I want to implement at least one more
command before I get to this.

Patrick