mjacob added a comment.
In D7631#123321 <https://phab.mercurial-scm.org/D7631#123321>, @mharbison72 wrote: > In D7631#123318 <https://phab.mercurial-scm.org/D7631#123318>, @mjacob wrote: > >> I like the name `--from` for the option. It would also make sense in combination with a possible future `--into` option. > > The unfortunate thing about `--from` is that it implies a range in `hg fold`, whereas here it seems to be a single(?) commit. It does make a lot of sense within the context of this command though (i.e. taking stuff //from// this commit). And it took me awhile to get comfortable with the meaning in `hg fold`, so maybe it can be changed to something else there? In any event, I don't want to hold this up over an experimental name, just thinking out loud. The `--from` in `hg fold` does not only have a different meaning, it’s also a flag that does not take an argument. The `hg fold` command itself takes revisions as arguments, so people might think they pass a revision to `--from` while they actually pass a revision to `hg fold` (having the same meaning as if it is passed to `-r`). Coincidentally, I was asked for help today from someone misusing the command that way. The `hg rewind` command also takes a `--from` option, this time with an argument. I expect that at least one of it might get changed eventually and I think we should not block this patch on that discussion. Of course, if someone comes up with a name that doesn’t have these problems and is intuitive, we should use that name. > I tend to agree with @martinvonz that setting the successor back to the commit it was absorbed into would be confusing, and seems like a way to split the stack into two stacks on that destination, with the corresponding merge conflicts. (Would the new "`hg evolve` => stabilize all descendants functionality" even stop at the break? I don't think it would.) I get what you're going for though if you want to track content. But it seems like it would cause non power users a lot of confusion. I prepared a patch that helps to prevent that the stack gets split: https://foss.heptapod.net/mercurial/evolve/merge_requests/126 As an example: echo a > a; hg add a; hg ci -m a echo b > b; hg add b; hg ci -m b echo c > c; hg add c; hg ci -m c echo a1 > a; echo b1 > b; hg ci -m 'change a and b' echo d > d; hg add d; hg ci -m d Graph: @ (4) d | o (3) change a and b | o (2) c | o (1) b | o (0) a First, let’s emulate a run of `hg absorb --from 3` that adds markers. hg up 3 hg uncommit --all hg up 2 --merge hg absorb --apply-changes hg prune -r 5 -s '6 + 7' --split Graph: @ (8) c | o (7) b | o (6) a * (4) d | x (3) change a and b — split using prune, uncommit as 6, 7 | x (2) c — rebased using absorb as 8 | x (1) b — rewritten using absorb as 7 | x (0) a — amended using absorb as 6 Now, `hg evolve -r 4` would have the following result without the above patch: o (9) d | | @ (8) c |/ o (7) b | o (6) a and with the above patch: o (9) d | @ (8) c | o (7) b | o (6) a REPOSITORY rHG Mercurial CHANGES SINCE LAST ACTION https://phab.mercurial-scm.org/D7631/new/ REVISION DETAIL https://phab.mercurial-scm.org/D7631 To: rdamazio, #hg-reviewers, martinvonz, marmoute Cc: mjacob, marmoute, mharbison72, martinvonz, pulkit, quark, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
