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

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D10893#166678 <https://phab.mercurial-scm.org/D10893#166678>, @mharbison72 wrote:
  
  > In D10893#166666 <https://phab.mercurial-scm.org/D10893#166666>, @martinvonz wrote:
  >
  >> In D10893#166662 <https://phab.mercurial-scm.org/D10893#166662>, @Alphare wrote:
  >>
  >>> This is indeed a very important quality-of-life feature and I'm +1 on adding it to Mercurial.
  >
  > +1
  >
  >>> - I remember sprint discussions wherein people warned that the semantics of `--rev` were not clear in the context of `amend` and suggested using something like `--into-rev`. I personally think `--rev` feels natural to me and I don't have strong objections to using it, but we should maybe ask the community (with a poll?) and keep the option open while implementing it.
  >>
  >> I initially called it `hg amend --into`, but then someone (in an unrelated discussion) mentioned `hg amend -i` yesterday and I thought that users might confuse `hg amend --into` and `hg amend -i`. I think most users think of the feature as `hg amend -r`, so I switched to that.
  >> My reason for initially calling it `--into` is that the command works on two revisions: the working copy and the target commit. Most hg commands default to working on the working copy and use `-r` to change that (for example, `hg branch` and `hg topic` change the branch name in the working copy by default, but you can change the branch/topic of other commits by passing `-r`). `hg amend` defaults to amending from the working copy and into the parent of the working copy. It seems unlikely that we'll add support for amending from an arbitrary commit into an ancestor of that commit. If we ever do that, we can make that `hg amend --from abc123 --into abc123^^` and keep `-r` as a deprecated alias for `--into`.
  >> Sounds okay?
  >
  > `-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. Also, adding the feature to `hg fold` is going to be more work because it's not in core.
  
  > 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.

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/20210622/9b4ab26e/attachment-0002.html>