From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Tue, 09 Dec 2025 18:29:27 GMT
Subject: Re: [PATCH v6 00/11] Introduce git-history(1) command for easy history editing
Message-ID: <b3ddfaa4-526b-41e3-b12a-0fec846ac7bc@app.fastmail.com>
In-Reply-To: <aS80z0DxAEBLba-M@pks.im>

On Tue, Dec 2, 2025, at 19:49, Patrick Steinhardt wrote:
>>[snip]
>
> I'm not sure whether that is something we want. I myself have the same
> commit on multiple branches quite regularly, as I tend to queue up
> multiple dependent patch series. But I wouldn't ever want a history edit
> to affect all of these branches myself, I really only want it to modify
> the branch I'm currently on.

Let’s say with the current subcommands I want to

• Split a commit because it contains unrelated formatting fixups
• I want to fix typos in a commit message and also add a paragraph

Then let’s say that there are three branches that contain these commits.
I can’t think of a case where I intend to only make these changes for
one of the branches.

A default of update-all-branches-in-range seems like the best default.

I also agree with everything Elijah wrote here:

https://lore.kernel.org/git/CABPp-BFtx7-vLFbVqbHar=UZb1CGX5=ufMA4hrJRkSYuB14_Tw@mail.gmail.com/

I haven’t used Jujutsu yet. But apparently it is much less
branch-focused. But for us who use branches and sometimes need
“dependent branches” or “stacked branches” the default equivalent of
`--update-refs` seems like a win to me.

Okay, maybe let’s say that I am really making intentionally-divergent
histories and one commit needs to be reworded for that divergent
context. That could happen. But I can’t imageine where I would do that.

>[snip]
> 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.

Maybe it’s surprising with the current defaults of other commands. But
for a new-and-better (for some circumstances or all) commands defaulting
to updating all branches sounds great.

I have read or heard about the “mega merge” strategy in Jujutsu.[1]
Being able to (this is how I imagine it could work) make a temporary
integration branch where N branches can be edited by making edits to
them and having all the branches be updated sounds amazing.[2][3] I have
found myself doing temporary integration branches where I make fixes on
top and manually cherry-picking them to the correct target afterwards.

🔗 1: https://news.ycombinator.com/item?id=44650248
† 2: Maybe the commits are “edited” and then the integration merges are
     re-done which sounds simple in the case of splitting commits and
     rewording commit messages. Well, “simple”, that’s easy for me to
     say from the peanut gallery. :) (I am aware that git-history(1)
     does not support merges in this current iteration)
† 3: I am thinking of the “common case” of `-update-refs` but what
     Elijah pointed out about “other interesting topologies” sounds even
     better. :) In the link from above:

     https://lore.kernel.org/git/CABPp-BFtx7-vLFbVqbHar=UZb1CGX5=ufMA4hrJRkSYuB14_Tw@mail.gmail.com/