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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jul 29, 2026, 13:24 UTC
Message-ID: <f5f7af53-df3e-4902-b350-8fcf8ccb02ad@gmail.com>
In-Reply-To: <xmqqfr15ruw7.fsf@gitster.g>

On 27/07/2026 04:09, Junio C Hamano wrote:

Show 17 quoted lines

> 
> * 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