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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Le 20 août 2025 à 13:39, Junio C Hamano <gitster@xxxxxxxxx> a écrit :
> 
> Patrick Steinhardt <ps@xxxxxx> 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 :)




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux