On Mon, Jun 15, 2026 at 4:22 AM Harald Nordgren
[off-list ref] wrote:

quoted

quoted

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

[snip]

quoted

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