Thread (7 messages) flat view 7 messages, 6 authors, 2021-09-30

Re: Feature Request: `git commit --amend-to`

From: Glen Choo <hidden>
Date: 2021-09-29 16:55:49

Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
[...] I think the problem
has more to do with how Git manages merges and conflicts and less to do
with having shortcuts in the CLI.
I think that users who'd like an --amend-to would probably be happy with
or might want to try out something like "hg absorb", which is something
I think we should have stolen in git already, but it's never too late.
Agree. I think some "hg absorb" features get at the heart of what I
meant, which is that users would benefit from making this merge conflict
resolution a lot simpler.
I.e. it's a "git commit --squash" on steroids, which tries to find what
commit to amend things into.
But this is an even bigger step up from what I was suggesting. I blame
my own lack of imagination for not even considering this possibility.

To me, what really sells the feature is the "history of lines" approach
cited in
https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercurial-4.8/:

  The automatic rewriting logic of hg absorb is implemented by following
  the history of lines. This is fundamentally different from the approach
  taken by hg histedit or git rebase, which tend to rely on merge
  strategies based on the 3-way merge to derive a new version of a file
  given multiple input versions.

Traditional 3-way merge is extremely frustrating when you find yourself
touching the same lines over and over in a rebase, and I think "history
of lines" maps quite cleanly to how humans think of lines. However I'm
not sure if Git has any machinery for doing this.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help