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

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  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
  - `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"

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