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

On Mon, Dec 8, 2025 at 11:53 PM Patrick Steinhardt [off-list ref] wrote:

On Fri, Dec 05, 2025 at 12:49:04AM -0800, Elijah Newren wrote:

quoted

On Tue, Dec 2, 2025 at 10:50 AM Patrick Steinhardt [off-list ref] wrote:

quoted

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.

FWIW, I agree with Elijah that (c) is the right end state. That's
perhaps not surprising given that that's what jj has been doing for
many years (as many of you know already, I'm one of the jj
maintainers). I think it's very rare that we hear from users that they
want to rewrite a commit and its descendants while leaving some of the
descendants in place. We have a `jj duplicate` command they can use,
but that won't move any bookmarks (branches) over. So if you have
bookmark `foo` with descendant bookmarks `bar` and `baz` and you want
to amend `foo` while moving `bar` over and keeping `baz` in place, the
simplest way is probably to duplicate all the necessary commit
(something like `jj duplicate -r main..bar`) and then manually move
over `foo` and `bar`. That seems like such a rare use case that we
haven't had a reason to make it simpler so far.

Regarding performance of (a), I would think that walking all
branches/tags until you reach the to-be-modified commit (or reach an
older generation) can usually be done quickly enough, but obviously
there are many others on this list who know that better than me :) But
I have also heard that some Git repos have tens (hundreds?) of
thousands of branches. Hopefully those refs are just on some server
where users won't run `git history`.

Do we already have logic like this in git-replay(1)?

Patrick