Re: What's cooking in git.git (Jul 2026, #12)

[Phillip Wood <phillip.wood123@gmail.com>]

On 27/07/2026 04:09, Junio C Hamano wrote:
> 
> * hn/history-squash (2026-07-20) 5 commits
>    (merged to 'next' on 2026-07-23 at 2790c83e45)
>   + history: re-edit a squash with every message
>   + sequencer: share the squash message marker helpers and flags
>   + history: add squash subcommand to fold a range
>   + history: give commit_tree_ext a message template
>   + history: extract helper for a commit's parent tree
> 
>   The experimental 'git history' command has been taught a new 'squash'
>   subcommand to fold a range of commits into a single commit, with any
>   descendants replayed on top.
> 
>   Will merge to 'master'.
>   cf. <DK1KIF2OI8IF.11188A3YEQV1C@lfurio.us>
>   cf. <DK1KIH6CXW0X.1U2V3GU8L6HB7@lfurio.us>
>   source: <pull.2337.v10.git.git.1784536024.gitgitgadget@gmail.com>

Oh, I'd missed this going into master. Has the implementation received 
any serious review? I've seen messages from a couple of people trying it 
out but I can't see anybody reading the code. Having a quick look 
through it assumes the presence of an UNINTERESTING commit means we have 
a BOTTOM commit. It then assumes that UNINTERESTING commit means we 
cannot reach any root commits. Both of those assumptions are false I 
think. As far as I can see it allows multiple tips so that with

   - A - B - C
          \
           D

it accepts "^A C D" but does not squash them correctly. It will refuse 
to squash "^A C" if there is a branch pointing to "B", but not if there 
only a branch pointing to "D" (in which case the branch is not 
rewritten). It also refuses to squash if there is a tag or remote 
tracking ref pointing to "B" which seems rather strange. None of the 
other history commands complain about rewriting commits that are pointed 
to by tags or remote tracking refs.

Without "--reedit-message", it will happily discard "amend!" and 
"squash!" commit messages even though the user creating them is a strong 
signal that they intended to use them to reword the commit. 
"--reedit-message" is a rather verbose option name which does not make 
sense to me as we're creating a new commit with a new message so we're 
not re-editing anything. I've commented elsewhere that I strongly 
dislike reusing the rebase squash message template for this command 
where we can squash fixups into multiple different commits at the same 
time. I'll try and go through the patches and produce some fixups, 
though that may not be until next week.

Thanks

Phillip