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:

quoted

On Wed, Dec 10, 2025 at 11:18:29PM +0900, Junio C Hamano wrote:

quoted

Phillip Wood [off-list ref] writes:

quoted

quoted

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.

quoted

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