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

> 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 <phillip.wood123@gmail.com> 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?

> > 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.