Re: [PATCH RFC 00/11] Introduce git-history(1) command for easy history editing
From: Patrick Steinhardt <hidden>
Date: 2026-01-06 15:40:31
On Mon, Dec 22, 2025 at 10:46:12AM +0000, Phillip Wood wrote:
On 19/12/2025 12:22, Patrick Steinhardt wrote:quoted
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.quoted
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".quoted
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.
Yeah, my next version of this patch series will do that now. I'll probably send it out tomorrow. Thanks for your thoughts! Patrick