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:

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?

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?)

If right now, when 'git history' applies each of those commits, then
rewriting all dependent branches seems to be a horrible idea.

But now that I've thought about the problem a bit I think we can avoid
that issue by implicitly identifying the range: it's all the commits
between the commit we're about to rewrite and HEAD. So, same as with
git-replay(1),

I think 'git rebase --update-refs' does the same as well.

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.