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

On Tue, Dec 2, 2025, at 19:49, Patrick Steinhardt wrote:

quoted

[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/ (local)

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/ (local)