It seems like I faild to have a look soon™

I just mean to use changelog=changelog in the super call... but this actually looks more robust.

Thanks for adding the test.

Since run-test has no idea where to put (?) line with the surounding change, they often end up preserved at start/end of the changeset section. This is probably just something like that.

In D8145#121270, @mharbison72 wrote:

In D8145#121269, @marmoute wrote:

Could we get a test for this? To make sure the hint looks fine and that the error code does not crash ?

The reason I didn't add a test (or see any changes to existing ones) is because the config property is baked into the config file generated by run-tests.py, so it never hits this path. But I did test by hand on Windows.

Could we get a test for this? To make sure the hint looks fine and that the error code does not crash ?

Since the line does not occurs on linux, this probably got affected by some other change without being noticed.

sure

You need to add (issue6276) in your changeset summary so that the ticket get closed when you land this.

I am also +1 for this change. divergence bookmark are close to "remote" bookmark and should not be exchanged. Especially because it open the way to divergent-divergent-bookmark and other hells.

This looks good to me.

The usecase looks correct, the test change seems correct and the test is good. I can't think of any issue here.

I would be nice to have test but I assume this is hard. The description seems clear so I trusting Kyle on this one.

Looks good. Thansk for the fix. I assume this should go on stable?

This patch seem (embarrassedly) right.

I've a couple of high level question:

Simple clear effective. Thanks for splitting

looks good to me. thanks for plitting

As per comment of Pulkit and I on D7730, please spin this test toward forbiding the prune while the rebase is in progress.

In D7730#119191, @pulkit wrote:

In D7730#117268, @marmoute wrote:

I think is would be simpler and sfare to prevent unrelated operation during rebase. If the user cannot prune here we won't have to deal with it. This woudl also apply to other operation that can alter the repository, like another rebase, amend or a pull. Starting using a unified and safe approach seems to provide more benefit with less chance of UI inconsistency.

I agree. We should disallow prune if an unfinished operation exists.

There don't seems to be any remaininf feedback on this.

In D8030#120781, @martinvonz wrote:

I don't like the idea of delaying this feature two months.

See my comment on D8030 https://phab.mercurial-scm.org/D8030#120771 This proposed change is part of a much bigger picture that requires wider discussion before we can safely proceed.

In D8035#120590, @durin42 wrote:

In D8035#119861, @marmoute wrote:

See my comment in D8030, the feature is interresting, but it seems to me that we should implement that through regular amend.

On the one hand that's a thought, but I mostly feel like the functionality belongs in hg copy since that's where I'd look for it.

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.

I had a longer discussion with @martinvonz on IRC on about this feature, he also pointed out to D7631 doing similar work for hg absorb.

In D7795#120551, @durin42 wrote:

In D7795#119774, @marmoute wrote:

The change seesm good to me. However kevincox proposal to use #[cfg(test)] for pad_node seems worth applying inflight.

For future reference, I'm going to add it here, but if you're going to the trouble of uploading a new revision, it would have been nice to do this and save reviewer toil.

The UI seems good, but it seems like we should have --dry-run supports and I find the help text confusing (I made improvement suggestion).

This is supposed to be a graft of something already accepted on default. So unless I did a mistake on the graft (cc @Alphare for checking) any feedback on this also apply on the default one.

phabricator seems to be very confused about the performance number formatting…

INTENDED FOR STABLE

INTENDED FOR STABLE

It looks like this series is introducing UI change of the same kind as the one @martinvonz is looking into for hg copy. I'll try to have a look at both of them tomorrow.