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

[Patrick Steinhardt <ps@pks.im>]

On Sat, Jan 10, 2026 at 06:14:00PM +0100, SZEDER Gábor wrote:
> 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