Re: [PATCH v9 0/7] Introduce git-history(1) command for easy history editing

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Jan 10, 2026, 17:14 UTC
Message-ID: <aWKI2BxszQuo1mRn@szeder.dev>
In-Reply-To: <CABPp-BEVZbN08zF2P0wNWuOZozc+tbWodfOjtiAkX+XhMiyC6w@mail.gmail.com>

On Fri, Jan 09, 2026 at 05:26:48PM -0800, Elijah Newren wrote:

Show 13 quoted lines

> On Fri, Jan 9, 2026 at 12:35 AM Patrick Steinhardt <ps@pks.im> wrote:
> > Changes in v9:
> >   - Rename `struct replay_ref_updates` to `struct replay_result` to make
> >     its semantics less focussed on ref updates, only.
> >   - Clarify and fix return codes of git-replay(1) so that we return 1 on
> >     conflict, 128 on an error and 0 on success.
> >   - The usual small improvements to commit messages.
> >   - Link to v8: https://lore.kernel.org/r/20260107-b4-pks-history-builtin-v8-0-18e9779e3a26@pks.im
> 
> I read through this series in detail; it's forming into shape nicely.
> I think there's still a number of small implementation things to fix
> up (see my comments on the individual patches), but the design looks
> good to me now.  I suspect we'll be ready to merge before long.

I don't think this should be merged until we have clear and feasible plans for future subcommands that will cause conflicts, to avoid painting ourselves into a corner, like when we couldn't change the not well thought out details of 'git switch/restore' anymore.