From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Tue, 03 Mar 2026 18:41:09 GMT
Subject: Re: [PATCH 0/8] history: introduce "split" subcommand
Message-ID: <CALnO6CDMF1G2AFMDXu=xhCv5XcgKm_-JXY2RvLc4TsD9Kh-K6Q@mail.gmail.com>
In-Reply-To: <20260302-pks-history-split-v1-0-444fc987a324@pks.im>

On Mon, Mar 2, 2026 at 7:15 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> Hi,
>
> this patch series introduces `git history split` as an easy way to split
> up one commit into multiple commits.

Exciting news, thanks!

> This subcommand has already been
> introduced in earlier versions of my git-history(1) patch series, but I
> eventually decided to evict them from this series so that we can rather
> focus more on basic decisions.
>
> In any case, the current version of this patch series matches (to the
> best of my knowledge) the latest agreements on the mailing list around
> its behaviour. Most importantly:
>
>   - It will ask for commit messages for both commits, not only the first
>     commit, which has been a bit of a discussion point.
>
>   - It is not possible to edit hunks. This results in a mode where
>     conflicts are not possible as the tree of the second commit will
>     always match the tree of the original commit. Conflict handling for
>     subsequent subcommands will be a bigger topic, as it probably
>     depends on support for first-class conflicts.
>
>   - We also update dependent branches, same as with the latest iteration
>     of `git history reword`.

Matches my memory. I think the dependent branches bit should probably
depend on the same --update-refs option, so I'll expect to see that
(not sure why we'd make any other choice ;).

-- 
D. Ben Knoble