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

[Patrick Steinhardt <ps@pks.im>]

On Wed, Aug 20, 2025 at 01:49:40PM -0400, Ben Knoble wrote:
> 
> > 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

Okay, I'll have a look at that. I'll probably not do that in v2 yet, but
will try to get it into v3.

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

At least initially I want to keep it simple, just to get this in at
first. So I'm trying to be quite defensive overall and die in all kinds
of situations that require more thought. That way it becomes way easier
to eventually extend the different subcommands to maybe lift some of the
current restrictions.

Patrick