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

From: Patrick Steinhardt <ps@pks.im>
Date: Jan 12, 2026, 13:03 UTC
Message-ID: <aWTxDlV5alleJnSq@pks.im>
In-Reply-To: <aWKI2BxszQuo1mRn@szeder.dev>

On Sat, Jan 10, 2026 at 06:14:00PM +0100, SZEDER Gábor wrote:

Show 19 quoted lines

> On Fri, Jan 09, 2026 at 05:26:48PM -0800, Elijah Newren wrote:
> > 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.

I agree that we need to think a bit about how we'll handle conflicts eventually. But I don't agree that this means we cannot already merge this series for subcommands that _cannot_ have conflicts as I don't really see how design decisions around handling conflicts would have an influence on subcommands that never have any conflicts in the first place.

The intent of this command is that it should allow users to easily handle certain common operations, without them having to worry about the underpinnings. So even if we eventually figure out that the replay subsystem is not a good fit for e.g. a potential `git history edit` command I don't think that this means that the whole status quo of `git history reword` would be impacted. And even if we eventuall _do_ decide to switch back to for example the sequencer subsystem I wouldn't expect that to impact the overall design of `git history reword` either.

So yes, I think we should have a discussion around how we can:

  - Handle conflicts in replay-based commands in general.

  - Support stacked branches workflows with conflicting commits.

From my point of view this leads into the direction of first-class conflicts in Git, and I think Elijah also leans into that direction. But it feels like a separate discussion to be had that is independent from the current proposed subcommands.

Also, with the new semantics that we have aligned on with dependent branches being rewritten I also think that we'll want to get the inital infrastructure out there to facilitate user feedback. Such feedback can also help us align on a better design for git-history(1) going forward.

Thanks!

Patrick