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

Ben Knoble [off-list ref] writes:

quoted

Le 21 août 2025 à 12:51, Sergey Organov [off-list ref] a écrit :

Junio C Hamano [off-list ref] writes:

quoted

Patrick Steinhardt [off-list ref] writes:

quoted

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

- 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.


[Footnote]

* "history edit" (aka "rebase") is an operation that "edits" the
  history, once the edit finishes, the result is *the* history you
  want, and the previous one is to be discarded (except for in
  reflog).  "cherry-pick" on the other hand is "I have this good
  thing on this development track, I want an equivalent _copy_ of
  it on _another_ track"---it merely is an easier and quicker way
  than typing the same thing yourself on top of the other track,
  and does not duplicate notes.

Unless I'm ignorant, "git rebase" (aka "history edit") lacks essential
feature though: in addition to saying: get "this" history and rebase it
"there", one should be able to say: get "that" history, and rebase it
"here" (aka cherry-pick on steroids), that also would eliminate the need
for 'git cherry-pick <range>' that (poorly) duplicates rebase
functionality.

But isn’t that

    git rebase --onto=<here> <that-upstream> <that>

Cause we end-up being on modified <that> (unless my memory fails me)
rather than on modified <here> when intent is to keep <that> intact.

? And why is that cherry-picking a range is a poor substitute [it is
rather rebase that duplicates cherry-pick ;)]?

Because rebase has a lot of useful features compared to cherry-pick,
such as --interactive, --exec, merges handling, etc. In fact, IMHO,
"cherry-pick" should better be Git plumbing, and every-day-user-needs
should be handled by "rebase".

Historically, when ranges support was added to "cherry-pick", it was
probably a mistake, as "rebase" appears to be a better place for needed
functionality, and what was needed is rather adding "--pick" support to
"rebase".

-- 
Sergey Organov