From: SZEDER Gábor Date: Fri, 19 Dec 2025 13:58:40 GMT Subject: Re: [PATCH RFC 00/11] Introduce git-history(1) command for easy history editing Message-ID: In-Reply-To: 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 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? 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.