Re: [PATCH RFC 00/11] Introduce git-history(1) command for easy history editing
Show 21 quoted lines
> Le 20 août 2025 à 13:39, Junio C Hamano <gitster@pobox.com> a écrit :
>
> Patrick Steinhardt <ps@pks.im> writes:
>
>> In the end, I'd like us to learn from what people like about Jujutsu and
>> apply those learnings to Git. We won't be able to apply all learnings
>> from Jujutsu, as the workflow is quite different there due to the lack
>> of the index. But other things we certainly can apply to Git directly.
>>
>> Note: This patch series currently builds on the cherry-pick infra.
>> As such, when one hits a merge conflict one needs to `git cherry-pick
>> --continue`, which is quite suboptimal. I didn't want to overpolish this
>> series before getting some feedback, but it is something I'll fix in
>> subsequent versions. Furthermore, the command for now bails out in the
>> case where there's any merge commits in the history that is being
>> rewritten. This is another restriction that can be lifted in the future.
>
> Two comments.
>
> - You would want to honor notes.rewriteref yourself, as cherry-pick
> does not and that is deliberate [*].
Show 7 quoted lines
> - It is a sensible design decision to limit it to linear single
> strand of pearls history. "history reword <commit>" when
> <commit> can be reached from many branches along linear history
> that rewrites all these commits on these branches would be handy.
> There may need some way to say "these branches are protected, if
> 'history reword <commit>' needs to touch commits on any of these,
> abort" and things like that.
This reminds me of looking at rebase’s update-refs through a mirror, and I think is similar to what jj actually does. In particular, editing a commit that is reachable from multiple non-overlapping branches could update all of them.
A reasonable heuristic for safety is “pushed,” but I would also want to be able to edit something in @{u}.. even if it’s in @{push} so that I can force-push a new version. I suspect jj might also have heuristics we can borrow.PS thanks all for being willing to borrow improvements! Reminds me of Neovim inspiring improvements in Vim, which I get to benefit from without switching :)
Ben Knoble <ben.knoble@gmail.com>