Thread (10 messages) 10 messages, 6 authors, 2026-01-06

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help