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

martinvonz (Martin von Zweigbergk) phabricator at mercurial-scm.org
Tue Jun 22 16:20:05 UTC 2021


martinvonz added a comment.


  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.
  
  Thanks for the quick review. I sent this out early to get feedback on the idea -- particularly on the fact that we'll have `hg amend --continue` and `hg amend --abort` -- before I wasted time going too far in the wrong direction.
  
  > I have a few questions/remarks however:
  >
  > - Just to make sure we're on the same page, you're suggesting to auto-rebase the stack i.e. what's between the commit to amend and the current working directory parent and nothing more, right? We probably want a non-default mode without the auto-rebase, I can see that being useful.
  
  Yes, exactly, I had intended for it to auto-rebase. Sure, I can add a `--no-rebase` flag too. When would you want that?
  
  By the way, I suppose we may want a `hg amend --stop` as well, but I probably won't implement that any time soon.
  
  > - 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?
  
  > - Maybe plug into `hg continue/abort` and suggest using it first, then `hg amend --continue/abort`?
  >
  > As a nit, I'd say the `.t` test should be using `(known-bad-output !)` and/or `(missing-correct-output !)` to better signal what is expected than the TODO.
  
  Ah, good point. Those are new enough that I haven't gotten used to using them yet. Will update the patch.

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: Alphare, mercurial-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-patches/attachments/20210622/b295a667/attachment-0002.html>


More information about the Mercurial-patches mailing list