--rev seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like --source, --from, --target?

In D7631#112414, @quark wrote:

--rev seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like --source, --from, --target?

Done. Used --source to match rebase.

I'm assuming no fundamental objections then? Removing the "RFC" part so it gets a proper review then.

Can you describe the feature a bit in the commit message. Specific things which I feel are missing:

• what happens to wdir changes
• what happens if source is a commit is not a head

I understand them but after reading the tests, so might be worth to add them to description.

Also, it will be nice if you add an entry in releasenotes.

Can you describe the feature a bit in the commit message. Specific things which I feel are missing:

Done

Also, it will be nice if you add an entry in releasenotes.

Done

In D7631#112604, @rdamazio wrote:

In D7631#112414, @quark wrote:

--rev seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like --source, --from, --target?

Done. Used --source to match rebase.

Is --exact from hg fold a better model? I don't feel strongly; I only mention it because hg rebase -s will take that revision and its descendants, so it's more like "stack" in my mind. I'm not sure how many other commands have -s off the top of my head, but @martinvonz
mentioned adding that to hg fix (probably in IRC), and I think mentioned the word "stack" in that context. So I might not be the only one to get slightly tripped up by that.

I'm assuming no fundamental objections then? Removing the "RFC" part so it gets a proper review then.

I like it.

In D7631#114393, @mharbison72 wrote:

In D7631#112604, @rdamazio wrote:

In D7631#112414, @quark wrote:

--rev seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like --source, --from, --target?

Done. Used --source to match rebase.

Is --exact from hg fold a better model? I don't feel strongly; I only mention it because hg rebase -s will take that revision and its descendants, so it's more like "stack" in my mind. I'm not sure how many other commands have -s off the top of my head, but @martinvonz
mentioned adding that to hg fix (probably in IRC), and I think mentioned the word "stack" in that context. So I might not be the only one to get slightly tripped up by that.

IMHO no, needing --exact is actually confusing to almost every user we've talked to, and they'd instead expect that to be the default behavior, with "fold up to this commit" being the one that needs a specific flag.

I'm assuming no fundamental objections then? Removing the "RFC" part so it gets a proper review then.

I like it.

Thanks

In D7631#112604, @rdamazio wrote:

In D7631#112414, @quark wrote:

--rev seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like --source, --from, --target?

Done. Used --source to match rebase.

Sorry I didn't notice until now, but --source makes me think it will behave like hg rebase --source and absorb from the given commit and all its descendants. I would have preferred --from (and maybe a --into for choosing which commits to absorb into in the future).

Sorry for the delay in replying here.

In D7631#120777, @marmoute wrote:

As explained in this comment https://phab.mercurial-scm.org/D8030#120771 I find the idea of usign a changeset in place of the working copy interresting. However, this is a larger big UX change that seems to deserve a wider discussion with more of the community involved. In particular I am not convinced about the --rev flag usage.
See the linked comment for more details.
(Sorry for the delay this will involves, I wish the idea had explicitly surfaced earlier).

The sprint is not happening and I don't think we should wait for the next sprint (fall?) to move forward with this. Here's a Plan Page I wrote down in response to @marmoute's request D8030: on https://www.mercurial-scm.org/wiki/RevisionAsWDirPlan. The decision we reached was to use the name --at-rev on that patch. However, and if I understood correctly, the general sentiment was not that all similar arguments (like the on in this patch) should use that but rather that we should pick a name that sounded for each command. So in the case of this patch, I suppose --from is fine? We should mark it EXPERIMENTAL, though.

I like the name --from for the option. It would also make sense in combination with a possible future --into option.

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

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.

In D7631#123321, @mharbison72 wrote:

In 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