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

From: Patrick Steinhardt <[email-masked]>
Date: Fri, 19 Dec 2025 15:09:39 +0100

On Fri, Dec 19, 2025 at 02:58:40PM +0100, SZEDER Gábor wrote:
> On Fri, Dec 19, 2025 at 01:22:03PM +0100, Patrick Steinhardt wrote:
> > On Wed, Dec 10, 2025 at 11:18:29PM +0900, Junio C Hamano wrote:
> > > Phillip Wood <[email-masked]> writes:
> > > 
> > > >> Its mostly because I don't like too much magic and because I think being
> > > >> explicit is always better than not.
> > > >> 
> > > >> So from my POV, I would expect "the simple case" to be "the simple CLI
> > > >> call" and if I want the tool to do magic and "rewrite all the
> > > >> things"^tm, that I would need to specify a flag for that.
> > > >
> > > > Thanks, that's useful to know. I'd assumed rewriting all the branches 
> > > > descended from the rewritten commit was the natural thing do do but 
> > > > clearly not everyone thinks it is.
> > > 
> > > It probably depends on the way one looks at the tool, as a building
> > > block (in which case less magic may be preferrable) or a complete
> > > solution for one part of workflow.  I probably fall into former camp
> > > more often than other people, but for this particular one, I tend to
> > > think it is less confusing if we moved all branch refs away from the
> > > commits that are obsoleted by rewriting/replaying.
> > 
> > Okay, so the majority of folks here seem to favor rewriting all
> > dependent branches, which is also the default that JJ uses here, and
> > git-replay(1) does it, too.
> 
> I can't find the word "conflict" in this subthread, so let me bring
> back that little history snippet from around the beginning of the
> subthread:
> 
>   Let's suppose I have this piece of history, I'm on 'branch2', and I
>   drop commit B.  Which commits will be rewritten and which branches
>   will be repointed?
>   
>      A---B---C---D   branch1
>               \   \
>                \   E---F   branch2
>                 \       \
>                  \       G---H---I   branch3
>                   \
>                    J---K---L   branch4
> 
> If we were to rewrite all dependent branches after dropping commit B,
> then besides 'branch2' we would rewrite 'branch1', 'branch3' and
> 'branch4' as well, right?
> 
> Now, let's suppose that dropping B would cause conflicts when
> rewriting commits G, H, I, J, K and L.
> 
> When does the user have to resolve these conflicts?

In the current proposed subcommands there cannot be any conflicts, as
both reword and split do not change the resulting trees.

> If not right now, then how exactly will those dependent branches be
> rewritten?  (I understand jj can store conflicts and they can be
> resolved later...  But are we there yet?)

No, we aren't. I think Elijah wants to work on that, and I agree that
for a subset of commands it might be a required feature.

> > the set of branches that we'd need to rewrite is any one
> > branch that points into that range. It keeps the UI simple as the user
> > still only has to think about a singular commit, should be sufficiently
> > fast to compute in most cases, and it allows mega-merge workflows like
> > JJ supports.
> > 
> > Does that make sense to everyone? If so, I'll revise my stance and will
> > adapt the current implementation to do exactly that.
> 
> I would very much prefer that the tool would only rewrite branches
> that I explicitly allowed to be rewritten, with an '--all' option that
> would allow the rewrite of all dependent branches.
> 
> Or at the very least there must be an escape hatch.

I agree a 100% about there being an escape hatch. You really don't want
to rewrite dependent branches in all cases. I'll include an option that
allows users to pick what to either:

  - Rewrite all dependent branches.

  - Rewrite only the currently checked-out branch or reference.

  - Only give us what _would_ happen, so basically git-replay(1)'s
    "--ref-action=print" mode.

Thanks!

Patrick