From: Ben Knoble <ben.knoble@gmail.com>
Date: Wed, 20 Aug 2025 17:49:40 GMT
Subject: Re: [PATCH RFC 00/11] Introduce git-history(1) command for easy history editing
Message-ID: <3600D877-4999-4EE3-8C1C-893E12D35B6A@gmail.com>
In-Reply-To: <xmqqms7tao9o.fsf@gitster.g>


> 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 [*].

Seconded

> - 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 :)