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

> On 19/12/2025 12:22, Patrick Steinhardt wrote:
> > 
> > But in our case we're not working with ranges, we are working with a
> > singular commit. In my head this meant that we'd have to basically do a
> > revision walk that starts from all of our branches so that we can figure
> > out which of them would eventually reach the commit that we are about to
> > rewrite. And that of course doesn't scale.
> 
> I'm not so sure about that. In repositories with lots of refs most of them
> are likely to be tags or remote tracking branches rather than local branches
> so I'd hope that the number of refs we have to walk was manageable. I'd also
> expect the commit we're rewriting to be relatively recent so the revision
> walk should quickly prune any branches that point to commits older than the
> one we're rewriting which should further reduce the number of commits we
> need to walk.
> 
> > 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), 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.
> 
> I agree that users should not have to think about commit ranges, but using
> an implicit range between the commit we're about to rewrite and HEAD will
> not rewrite all the branches descended from that commit, instead it will
> behave like "git rebase --update-refs".
> 
> > Does that make sense to everyone? If so, I'll revise my stance and will
> > adapt the current implementation to do exactly that.
> 
> I'd much rather rewrite all the branches descended from the commit we're
> about the rewrite rather than those that happen to point into the revision
> range between that commit and HEAD as I think that ends up being confusing.