Re: [PATCH v6 00/11] Introduce git-history(1) command for easy history editing

>
> On Fri, Dec 05, 2025 at 12:49:04AM -0800, Elijah Newren wrote:
> > On Tue, Dec 2, 2025 at 10:50 AM Patrick Steinhardt <ps@pks.im> wrote:
> > > Consequently I'm leaning more into the direction of doing nothing. It's
> > > not really clear to me that this is a bug, and we still can introduce a
> > > flag in the future that opts into the behaviour of rewriting relevant
> > > branches. That behaviour certainly can be useful, but I'd claim that
> > > it would be rather surprising to the user if that was the default.
> >
> > Well, as I stated above, this is basically copying what I view as the
> > fundamental design mistake of git-rebase.  The many other points of
> > feedback I had on this series (e.g. extended headers, reusing replay's
> > walking, etc.) are things I could easily negotiate on; this one
> > bothers me much, much more.  To me, it ruins the command and makes me
> > feel it is unsuitable for inclusion in git; this is, after all, the
> > kind of thing that made me decide to write yet another command to
> > workaround such a flaw.  If the series is merged with this behavior,
> > I'm going to be in the awkward position of feeling I need to actively
> > recommend against its usage unless _and until_ we either
> >
> > (a) check that a commit is only part of one branch before proceeding,
> > (b) always require the user to specify with a flag how to handle
> > commits that happen to be part of multiple branches (even when a
> > commit only happens to be part of one branch, in order to allow us to
> > not bother checking whether it's part of more),
> > or
> > (c) rewrite all branches that contain the given commit by default
> > (with an option to only rewrite the current one).
> >
> > That said, obviously the choice of whether the series is merged isn't
> > up to me.  And maybe I'm in the minority, and others don't care about
> > this issue at all.  But it's how I feel about it.
>
> I guess it's a matter of workflows and tastes, and there's never going
> to be the one correct way of doing things. I don't think (b) is a good
> option as it makes things more complex even for the simplest cases. But
> I wouldn't be opposed to a combination of (a) and (b) if we can
> implement (a) efficiently.
>
> Do we already have logic like this in git-replay(1)?