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

From: Phillip Wood <[email-masked]>
Date: Mon, 22 Dec 2025 10:46:12 +0000

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.

Thanks

Phillip