From: Patrick Steinhardt <ps@pks.im>
Date: Tue, 09 Dec 2025 07:53:33 GMT
Subject: Re: [PATCH v6 00/11] Introduce git-history(1) command for easy history editing
Message-ID: <aTfVfenbwY685fDZ@pks.im>
In-Reply-To: <CABPp-BFtx7-vLFbVqbHar=UZb1CGX5=ufMA4hrJRkSYuB14_Tw@mail.gmail.com>

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)?

Patrick