Re: [PATCH v8 0/5] history: add squash subcommand to fold a range
- From
Matt Hunter <m@lfurio.us>
- Date
- Jul 14, 2026, 04:44 UTC
- Message-ID
- <DJY0QSJYNG0J.210HZQH198Y1N@lfurio.us>
- In-Reply-To
- <pull.2337.v8.git.git.1783674396.gitgitgadget@gmail.com>
On Fri Jul 10, 2026 at 5:06 AM EDT, Harald Nordgren via GitGitGadget wrote:
Show 21 quoted lines
> Adds git history squash <revision-range> to fold a range of commits. > > Changes in v8: > > * --reedit-message now builds the same editor template as git rebase -i > --autosquash: fixup!, squash! and amend! commits are grouped under the > commit they target instead of shown in commit order, and an amend! > replaces its target's message. > * A fixup!, squash! or amend! is refused only when its target is outside > the range, so several fixups for an in-range commit fold together. A > range that is entirely markers for one below-range target is combined > into a single commit, keeping the last amend! message. > * Merges inside the range are folded when the range has a single base, with > no dedicated opt-in flag, --ancestry-path ensures only commits descended > from the base are folded, and a range reaching more than one base is > rejected. > * Rev-list options are accepted and sanitized the way git replay does, > forcing the walk order back with a warning, which also fixes git history > squash -- --reverse slipping past the previous option check. > * Kept this as an explicit squash subcommand rather than making > --reedit-message the default or renaming the command.
This feature looks like it's coming together pretty well imo. I just have one observation I want to comment on:
I noticed that 'git history squash <range>', when --reedit-message is omitted, will ignore any amend! message in the range that targets the first folded commit.
On the surface, this makes sense. The feature is pretty explicit that it will faithfully stick with the first commit's message, unless modified by use of --reedit-message.
However, this edge case is a little surprising, given that 'git history squash' seems to be aware of the semantics of fixup!, amend!, and squash! messages whether --reedit-message was given or not. For instance, the default command notices when the range contains a squash! commit whose target is elsewhere (a useful feature). It seems consistent then, that the default command would incorporate an amend! it is aware of when placing the "first commit's" message in the resulting squash. This seems useful to me as well.
At the same time, I can understand why the current implementation does what it does. So I'm not entirely sure what the correct answer is here.
I'll mention as well that I really like the decisions made for how this command handles squashing a bunch of related fixups. This "fixup consolidation" is a use-case that this command may steal away from rebase for me. And the way a final amend! is handled in this case is what got me thinking about it in the general case.
Thanks for the work on this topic!