Any reason why py3-chg is not included?

This series fails to apply on current default tip.

In D8148#121295, @pulkit wrote:

Looks good to me, can you add an entry to relnotes/next?

test-check-code.t says hi:

Looks good to me, can you add an entry to relnotes/next?

Amended the following in flight to test-check-format.t happy:

Converted line endings to unix one in flight.

This fails to apply on tip of stable branch. Kindly rebase and resend.

Will be nice to add some release notes either in BC section or in features section stating debugmergestate now supports templates and can be used by scripts/editors.

The commit message has a mention of uncopy which needs to be removed.

This one fails to apply on tip of stable branch. Can you rebase and resend?

Sorry for late reply. By changing the default, I am afraid about the cases where a user has broken repository and we only recover the transaction and don't verify. I am not sure what those cases are. Also I don't know why recover used to do verify in the first place. Maybe @durin42, @marmoute or someone else knows?

In D8050#120043, @Alphare wrote:

In D8050#119795, @marmoute wrote:

This is straightforward, however having some performance number would be great.

This is simply an API change related to the performance improvements in previous patches. Is this commit where we should put those performance numbers?

Is this and next one targeted for stable branch? I see a mention about that in next patch.

In D8096#120082, @valentin.gatienbaron wrote:

I thought it was generally preferred to have the False in the code, for extensions that want to call the function?

Nice! Looks good to me. Can you add a releasenotes entry in relnotes/next?

This one failed to apply on latest default, needs rebase.

This is fixing some debian packaging issue, so is it targeted for stable branch?

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.

@marmoute wants the series to be pushed for stable so that the yaml files are present on that branch and heptapod can run tests for that too. That seems okay to me, however I will wait for 3-4 days to see if anyone has objections.

The whole absorb extension is experimental, so even if we want to change -i somehow in future, this looks fine.

I am seeing this failure, hope it helps:

test-rename-merge1.t fails with this patch. Looks like there is one more instance of prompt which is not needed anymore. I didn't amend that in flight as I was not sure.