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

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  In D10893#166899 <https://phab.mercurial-scm.org/D10893#166899>, @martinvonz wrote:
  
  > 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:
  >>>>
  >>>>> 
  >>
  >> 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)?
  
  That is a very good question, that I have not been able to have a clear opinion on so far. (I did not though about it too much either).
  
  I can see argument for both, "if it is integrated somewhere else, it should no longer be in the wdir() diff" and "This is asking for trouble, we better leave it around".
  
  In the usecase were a small type fix is cast-away in an ancestor and the change is not really relevant to the WC, dropping it is "cleaner" and won't introduce conflict.
  On the other hand If the usecase is to send something more conflictful and/or more relevant to the WC, keeping it around might make sense ?
  
  I suggest we start with the path of least resistance (probably keeping it in the WC then) and add a # XXX TODO comment near the experimental config so that we don't forget about that before getting the feature out of experiment.
  
  >> - `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.
  
  note: In the case I describe above, this would not be simply a "on the fly patch edition" (pressing "e" in the curses UI) since this would probably involves running tests and writing possibly other codes to make it work fine.
  
  I don't think I understand how the "e" editing can introduce more conflict. Can you elaborate ?

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