Not done reviewing, but I need to switch over to other work. Here are a few comments for now.

In D8118#121598, @pulkit wrote:

This series fails to apply on current default tip.

Moved formatting fix to parent patch

Moved formatting fix to parent patch

We already have tests for this (grepping for "unwanted changes" in tests/ should be enough to find them).

In D8146#121279, @mharbison72 wrote:

In D8146#121277, @martinvonz wrote:

In D8146#121271, @mharbison72 wrote:

In D8146#121267, @marmoute wrote:

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

Makes sense for why it was missed, but I bisected it back to the referenced commit. I know @martinvonz made some other related changes prior to that commit that had similar test fallout on Windows, but it isn't obvious to me why the referenced commit would change the order of when the background thread spins up.

Perhaps the line doesn't actually happen before that commit? You can try removing the (?) in the commit before my commit and see if that line is actually printed. I'm thinking that that commit pushed the number of files to close above some threshold that made it get printed. In that case, it was probably some of my earlier commits that made it no longer get printed and we just didn't notice since (?) means optional (no error if it doesn't get printed).

I can confirm that it was required in e1ecfc7c84be, and reconfirmed that it is needed in the latest code by removing the line from both. I'm not too worried about why it popped up- it just seemed odd that it didn't with the earlier followup patch I added to fix similar conditionalizing of this exact text elsewhere, and the commit where it started failing looked innocuous.

In D8146#121271, @mharbison72 wrote:

In D8146#121267, @marmoute wrote:

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

Makes sense for why it was missed, but I bisected it back to the referenced commit. I know @martinvonz made some other related changes prior to that commit that had similar test fallout on Windows, but it isn't obvious to me why the referenced commit would change the order of when the background thread spins up.

In D8122#120939, @mharbison72 wrote:

Does this also allow extensions to be bundled in the exe, or are you thinking we need to leave the extensions outside the binary?

fixed stale uses of -r in commit message and transient code

fixed stale uses of -r in commit message and transient code

fixed stale uses of -r in commit message and transient code

No longer needed now that we've renamed -r to --at-rev.

In D8030#120899, @martinvonz wrote:

In D8030#120786, @marmoute wrote:

In D8030#120781, @martinvonz wrote:

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

I believe we need wider discussion about this before going further, this is an interresting change but we cannot rush it. This not necessarly result in a to a 1.5 month delay if a proper community discussion happens before that. Can you create and fill a Plan page and start a community discussion around this?

! In D8030#120861, @Alphare wrote:
I'm fine with marking the use of -r experimental. I don't like the idea of delaying this feature two months. Any problem with marking it experimental for now? As usual with experimental features, that will allow us to rename the flag (and change other behavior) before we take it out of experimental.

Aside from (obviously) @marmoute, both Jordi and I had an instant reaction of "what?" when we learned what --rev meant.
I think that this goes against the intuition of at least a few people that are very accustomed to hg. While being able to operate on any particular rev could be a good - even great - idea in general, I am very uneasy about using --rev to qualify that target. I don't know if --target-rev is an option, but something similar would be much clearer that an already *extremely* common flag. This would shift the semantics of --rev in some commands and not in others.

I'm fine with --target-rev if that's what people prefer. I find it a bit weird to not use --rev` but that may just be because I'm been thinking of the working copy as a commit for longer than most.

In D8030#120786, @marmoute wrote:

In D8030#120781, @martinvonz wrote:

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

I believe we need wider discussion about this before going further, this is an interresting change but we cannot rush it. This not necessarly result in a to a 1.5 month delay if a proper community discussion happens before that. Can you create and fill a Plan page and start a community discussion around this?

This one replaces D8113.

In D8113#120803, @martinvonz wrote:

I was worried that the new version might be crashing in some cases (I specifically worried about indexes out of range in the state list). To test that, I added hg debugmergestate before every hg resolve call in the test suite. That showed two different bugs. Feel free to de-queue this patch or I'll send updates later (maybe tomorrow). Sorry that I didn't think to test that before the patch got accepted.

I was worried that the new version might be crashing in some cases (I specifically worried about indexes out of range in the state list). To test that, I added hg debugmergestate before every hg resolve call in the test suite. That showed two different bugs. Feel free to de-queue this patch or I'll send updates later (maybe tomorrow). Sorry that I didn't think to test that before the patch got accepted.

In D8030#120771, @marmoute wrote:

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.
From that discussion I understand there is a wider objective for many mercurial commands to gain the ability to use a specific revision in place of the working copy. (eg: hg amend, hg aborb, hg copy, etc…)
The idea is quite interresting and can unlock powerfull capabilities. However, this is a rather big UX project, I think we need a step back and think about this idea on a large scale. I am thinking at least a Plan page with a wider study of the command that could be impacted how the UI will be consistent. This allows a wider set of the community to chim in on such a big project.
A concret issue I current have with the plan is the planned --rev flag usage. To me, and other people around me, something like hg amend --rev X would means "amend change from the working copy into revision X". likewise hg absorb --rev REVSET would absorb the working copy change into the REVSET set of revisions. So the use of --rev is surprising to some and should be discussed. Maybe the --change flag (used, but hg status and hg diff) would be more suitable? Maybe a global flag --change-as-wdir that would work for any commands ?
This is the kind of question I would like to see discussed more widely before we invest more in this idea (Idea, that I find interresting overall). I added this as a topic for the upcoming sprint.
(Sorry for the delay this will involves, I wish the idea had explicitly surfaced earlier).

In D8113#120746, @martinvonz wrote:

In D8113#120745, @pulkit wrote:

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.

Ah, good point, will do.

In D8113#120745, @pulkit wrote:

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.

Making this patch part of D8113 (this patch was never meant to be queued on its own).

In D8029#120701, @pulkit wrote:

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

In D8113#120695, @durin42 wrote:

Why can't we add templater support to debugmergestate instead?

In D8033#120581, @durin42 wrote:

Oddly, this had some rejects (I didn't look why) but i"d be happy to see this earlier in the series.