From: Phillip Wood Date: Tue, 04 Aug 2026 09:36:31 GMT Subject: Re: [PATCH v10 3/5] history: add squash subcommand to fold a range Message-ID: <49186d54-f7a4-40ff-a88f-62d9f44fdbcd@gmail.com> In-Reply-To: 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