[Commented On] D10893: amend: add a useless initial version of `amend -r REV `

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D10893#166756 <https://phab.mercurial-scm.org/D10893#166756>, @mharbison72 wrote:
  
  > In D10893#166684 <https://phab.mercurial-scm.org/D10893#166684>, @martinvonz wrote:
  >
  >> In D10893#166678 <https://phab.mercurial-scm.org/D10893#166678>, @mharbison72 wrote:
  >>
  >>> 
  >>
  >> Also, adding the feature to `hg fold` is going to be more work because it's not in core.
  >
  > Hmm, yeah.  Are you planning on implementing the `--from abc --into xyz` case in the near term?  I probably just wasn't clear enough that I thought this (currently out of scope) functionality is what might belong elsewhere.
  
  Nope, no plan to do that. I just used it to explain the argument that `hg amend` operates on two "commits" (the working copy and another commit) and it would be consistent with at least `hg branch` and `hg topic` for `hg amend -r` to be about which commit to use instead of the working copy (presumably moving the changes from that commit into its parent).
  
  >>> The other general thought I had on this is maybe `absorb` functionality can be leveraged to avoid the merge conflicts when rebasing, but I don't understand that code at all in order to help.  I suppose you'd need to have the "absorb this line into a specific revision" functionality implemented that's been talked about before.  But the functionality in general seems more absorb-y than amend-y to me.
  >>
  >> I suspect it would be hard to convince absorb to do this operation. As you said, the "absorb this line into a specific revision" functionality doesn't exist. I think it will be much easier to use rebase internally for this.
  >
  > Yeah, after I hit "send", I wondered if absorbing to an __ancestor__ of a commit that last changed the line being absorbed would cause merge conflicts, and require extra work.
  > At any rate, please don't take any of this as a NACK or discouragement- I think the functionality is useful in whatever form.  I'm just thinking out loud because I'm not sure what all is planned, and trying to get the right UI metaphor in my mind.  Since it's marked experimental, if people eventually feel it's more related to absorb from the user POV, we could just dispatch that arg on absorb to the rebase-based implementation you're working on, similar to how the amend command is routing it to a completely different implementation here.
  
  Sure, no problem :) We have talked internally at work about some kind of interactive `hg absorb` that lets you decide which commit each line should go into. That sounds similar to what you're thinking of.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D10893/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D10893

To: martinvonz, #hg-reviewers
Cc: mharbison72, Alphare, mercurial-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-patches/attachments/20210623/56d45775/attachment-0002.html>