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

[mharbison72 (Matt Harbison)]

mharbison72 added a comment.


  In D10893#166684 <https://phab.mercurial-scm.org/D10893#166684>, @martinvonz wrote:
  
  > In D10893#166678 <https://phab.mercurial-scm.org/D10893#166678>, @mharbison72 wrote:
  >
  >> 
  
  
  
  >> `-r` seems reasonable to me.  The `--from abc --into xyz` form sounds more like a non contiguous `hg fold` to me.  I haven't given any thought to if adding that functionality there would make the UI too awkward, given that you can select multiple source revs to fold.
  >
  > Well, `hg amend` and `hg fold` sound the same to me :) To me, the difference seems to be that `hg fold` is about folding many commits, while `hg amend` is about only two.
  
  Ah, OK.  The distinction to me is `hg amend` works on `wdir() + .` and `hg fold` works on 2 or more __commits__.  This is just extending the former's `.` to `::.`.  This doesn't propose to handle `--from abc --into xyz`- all I meant was if it does become a thing some day, it sounds like maybe a different command anyway.  I could also see the `-r` arg here accepting multiple revisions when `--interactive` is given someday, to allow the user to amend in bits and pieces while rebuilding the stack one commit at a time, and that would be outside your definition of `hg amend`.  I'd still expect that to be the same command as this, but I'm not trying to feature creep it :-)
  
  > 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.
  
  >> 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.

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/af729d0e/attachment-0002.html>