Re: [PATCH v10 3/5] history: add squash subcommand to fold a range

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

Hi Harald

On 03/08/2026 17:35, Harald Nordgren wrote:
>> These patches can be fetched with
>>
>>    git fetch https://github.com/phillipwood/git wip/hn/history-squash/v10-early-part
>>
>> note that they do not support editing the commit message of the
>> squashed commit.
> 
> Thanks, what should I do with it?
> 
> Is it a replacement for my branch, or should it apply them as fixups
> (if so how do we handle the lack of re-edit support)?

I'd start by reading through them and asking any questions you have 
about the implementation or the reasoning behind it. Before you send a 
new version patch 3.5 needs some work to print the branch names (that 
shouldn't be difficult the ref-filter has functions to handle sorting 
and printing the contents of the ref_array) and patch 3.6 needs tweaking 
to work with editing the commit message (I'm afraid I haven't given that 
any thought yet). We should also think about how to split the series up 
to make it easier to review: the last patch in v12 is over 1500 lines of 
new code and tests. It would be better if we could split it into a few steps

1 - add the skeleton command with option parsing and the checks for
     rev-list arguments and BOTTOM commits.
2 - walk the revs and add all the error checks for multiple tips, merges
     outside the range, root commits etc.
3 - add the check for branches that point into the range.
4 - add the code that creates the new commit and its message when it is
     not being edited.
5 - add support for editing the commit message.

That makes each logical step easier to review and gives you the 
opportunity to explain the rationale for the design and implementation 
of each step in the commit messages.

I see you've sent another version already - it would have been helpful 
to wait for a response to this message first. The mailing list is 
asynchronous so you wont always receive an immediate response to your 
messages. Each time you send a new version you should think what it is 
you want to achieve from that iteration. Simply sending a series of what 
are in effect works-in-progress without any indication of what feedback 
you are looking for just clutters the list and makes it hard for 
reviewers to keep up.

Thanks

Phillip