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

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D10893#166881 <https://phab.mercurial-scm.org/D10893#166881>, @marmoute wrote:
  
  > In D10893#166669 <https://phab.mercurial-scm.org/D10893#166669>, @martinvonz wrote:
  >
  >> In D10893#166668 <https://phab.mercurial-scm.org/D10893#166668>, @Alphare wrote:
  >>
  >>> In D10893#166666 <https://phab.mercurial-scm.org/D10893#166666>, @martinvonz wrote:
  >>>
  >>>> Sure, I can add a `--no-rebase` flag too. When would you want that?
  >>>
  >>> This would be for small adjustments that have no real impact on what I'm currently working on, I can just throw the amends one after the other. It's pretty niche, but not hard to implement so I thought I'd ask.
  >>
  >> I'm not sure I follow. Let's say you have this history:
  >>
  >>   @ C
  >>   |
  >>   o B
  >>   |
  >>   o A
  >>
  >> You then make some change and run `hg amend -r B --no-rebase`. You get this:
  >>
  >>   @ C
  >>   |
  >>   x B
  >>   |
  >>   | B'
  >>   |/
  >>   o A
  >>
  >> Presumably the working copy is now clean again? However, that means that you can't make changes that build on top of the previous amend.
  >> You then make some further changes in the working copy. What do you do now? If you do `hg amend -r B`, you would presumably get divergence. Should we allow `hg amend -r B'`? I had been thinking that we restrict `hg amend -r` to only amend into an ancestor just to keep it simple and because that seems like what people want in 99% of cases.
  >
  > There is a bunch of small usecase for `--no-rebase` (that should probably be named `--no-evolve`
  > In simple case, the user knows he will amend various bits of the current working copy in different commit of the stack and prefer to run the evolution only once (to reduce conflict resolution and/or to reduce markers creation).
  > In more advanced case, this might be actually needed to avoid a loop of complicated and unnecessary conflict resolution. Lets imagine the following scenario:
  >
  >   @ C
  >   |
  >   o B
  >   |
  >   o A
  >
  >
  > - There are change to amend in A, but they will need adjustement to actually work in A and they will conflict with some content in B (then C)
  > - There are change to amend in B, but they will conflict with the change in A and with some change in C
  >
  > Without `--no-evolve`, this would mean the following operation
  >
  > - `hg amend -i --rev A` → this requires conflict resolution when evolving B, then C; conflict is resolved with non final content
  > - `hg amend -i --rev B` → this requires conflict resolution when evolving C; conflict is resolved with non final content
  > - `hg update A; hack hack hack; hg amend; hg next` this requires conflict resolution when evolving B,
  > - `hack hack hack; hg amend; hg next` this requires conflict resolution when evolving C,
  >
  > With `--no-evolve`, This can simply be:
  >
  > - `hg amend -i --rev A --no-evolve` → no conflict resolution yet
  
  I imagine that the selected changes are removed from the working copy after this step. Is that what you were thinking as well? Or were you thinking that they would remain in the working copy as well (more like `hg rebase --keep` if you think of the working copy contents as a commit)?
  
  > - `hg amend -i --rev B --no-evolve` → no conflict resolution yet
  > - `hg update A; hack hack hack; hg amend; hg next` this requires conflict resolution when evolving B; with final content
  > - `hack hack hack; hg amend; hg next` this requires conflict resolution when evolving C,
  >
  > So the `--no-evolve` reduced the number of conflict and all the conflict we had to resolve were "meaningful", using "final content"
  
  Makes sense. On the other hand, if the changes you want to amend into A require you to edit the patch (pressing "e" in the curses UI), then it seems like you'd get additional conflicts by using `--no-rebase/--no-evolve`. So both `--rebase` and `--no-rebase` seem to be useful for avoiding conflicts in some cases.

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