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

Mon Jun 28 17:17:04 UTC 2021

martinvonz added a comment.

  In D10893#166901 <https://phab.mercurial-scm.org/D10893#166901>, @marmoute wrote:

  > 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.

  I'll start with not even having the flag :P When automatically rebasing the descendants, it seems more clear that the changes should not be left in the working copy. I was planning on explicitly rebasing them and not leaving them in the working copy, not relying on them disappearing only because the changes were already present in an ancestor afterwards. To clarify, I was planning for it to do this:

  1. Create temporary commit from working copy
  2. Rebase temporary commit to target (not using `--keep`)
  3. Fold the rebased commit into the target
  4. Rebase descendants, not including the temporary commit from step 1

  One could imagine using `--keep` in step two and include the temporary commit in step 4 and just rely on it becoming empty. However, if there were conflicts to resolve in step 2, then you'd run into conflicts again in step 4. It seems better to avoid that.

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

  It can introduce more conflicts under the assumption above (that at least I had) about `hg amend -r` not leaving the changes in the working copy as well. Let's say you have some file that contains content "a" in commit A. The file is unchanged between A and the working copy parent. Your working copy now contains "c" in this file. You realize that the contents in commit A should have been "b", so you run `hg amend -r A -i` and edit the diff from "change 'a' to 'c'" to "change 'a' to 'b'". When the user then confirms their selection, I was planning to create a commit for "change 'a' to 'b'" and another commit on top for "change 'b' to 'c'" (just like how `hg ci -i && hg ci` would create two commits). I was planning for the first change to go through steps 2 and 3 and 4 from above. However, the "change 'b' to 'c'" bit would also be rebased in step 4 and would apply cleanly. If we leave the changes in the working copy as well, then they'd conflict when they were rebased onto the folded commit (whether that rebasing was done by `hg amend -r A -i --rebase` or by `hg amend -r A -i; hg evolve`).

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