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 <ps@pks.im> wrote:
>> On Fri, Dec 05, 2025 at 12:49:04AM -0800, Elijah Newren wrote:
>>>
>>> (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
>