In D11680#179988, @marmoute wrote:

The ability to use --no- variants is fairly new (a couple of year maybe ?), but I (and others) have been trying to put it to good use since then. Since is quite new I don't think they so many of of such flag yet, but a notable example of that approach is --merge that I use daily.

In D10538#179907, @marmoute wrote:

The test near silently skipping is another issue we should tackle. What do you think of the way forward I suggested (flag + env-variable) ?

In D11715#179846, @mharbison72 wrote:

Now that the fallback function is always being built

I'm not sure the etiquette here; I'm accepting the revision since it obviously fixes a bug, but still would like the comments to be considered/responded to?

In D10538#179050, @marmoute wrote:

I feel like the proposal is going in the wrong direction because it make a more diverse set of version passe the version checks while I feel like we need to more toward a narrower check. Different formater version tends to produce different results and it seems saner to pin the project to specific versions (that we update from time to time).

Looks good to me aside from the nit and the pulkit's comment. Not sure on etiquette here (whether I should mark as accepted or not), defaulting to not marking as accepted until all outstanding comments are addressed.

In D10538#178945, @marmoute wrote:

In D10538#164634, @marmoute wrote:

The CI running on Heptapod is available to any developer who pushs draft to it, and it uses the "correct" black version, pinned in the docker image what we uses for the CI.
Something we have been entertaining for a while is to a manually trigger a CI "job" that would run the black formatter one current stack and push back the result to heptapod. This would give a simple option to format with the right version when the CI complains about it. It looks like it could fit the @spectral usecase here.
(The docker image can be easily updated to newer version when appropriate by anyone creating a Merge request here: https://foss.heptapod.net/octobus/ci-dockerfiles/)

While this is/would be very useful, it requires manual action, I think?

Yes, it would be an optional way for people who don't want (or can't easily) install the required tools at the required version.

My goal is to prevent that. I want/need there to be a single command I can run that ensures a commit is ready to land: correctly formatted, tests pass, etc.; there's a reason these check-format tests exist as tests. :/

I am not challenging that, but whatever we do with these tests need to be viable at the project level and it don't seems like using too many, incompatible, version of the formatter would fly well.
I think the baseline for the project should be "the CI shoul stay green" which implies "new changesets should keep the CI green". Running tests locally is a good way to quickly catch errors, but eventually, the only way to validate this is to run the CI on submitted changeset. Something that is now easy to do for a couple of years.
However this implies to make sure the version of formatter used by developers is aligned with the one used by the CI. Which should not be to complicated.

In D11495#176286, @martinvonz wrote:

In D11495#176284, @durin42 wrote:

I think that's a buggy test? @martinvonz and @spectral might have an opinion.

I think I did it that way because I felt that hg manifest is a debug command so it might be useful to have the information about excluded trees there.

In D10538#164587, @durin42 wrote:

In D10538#160330, @spectral wrote:

I think that the worst that can happen with this change is:
a. clang-format makes a backwards-incompatible change

This has happened (in the past, anyway) pretty regularly. When I asked djasper about it, his answer was "you should check in the clang-format binary you want to test against" which we obviously can't do. :/

Looks like these changes were absorbed into 8fcc0a82, so this is unnecessary now.

In D10538#160300, @joerg.sonnenberger wrote:

I'm not sure that this is an improvement. We discussed whether we want to hard-wire the version even stricter ("exactly version 11"), especially because it is hard to predict when the output is going to change again.

In D10470#160272, @Alphare wrote:

This breaks the CI https://foss.heptapod.net/octobus/mercurial-devel/-/pipelines/21383.
Could you send a followup please?

I thought I'd run the entire test suite and it passed before sending. Sorry about that! Fixed fncache and inherit-mode by not writing out the narrowspec backup in the mkstemp call. I'm not getting any failures in test-check-code.t, can you share what ones you're seeing?

(marking comment as resolved, not sure what the exact policy is here :))

In D9952#159267, @marmoute wrote:

@spectral, What is the range of code you want to ensure a race with ? and how is the synchronization happening to reach it ?

I'm unable to reproduce. I've run the test over 10,000 times (I added a #testcases a b c d e f g h i j k l m n o p q r s t u v w x y z so it ran 26 times each run, and I've run over 300 instances of that like run-tests.py -j26 -l --chg test-racy-mutations.t, over 100 with -j108, and other combinations (with and without the added testcases, with and without --chg, etc.)

I'm apparently not going to resolve the comments, sorry for leaving this open so long.

In D10386#158301, @pulkit wrote:

Fails to apply cleanly on current tip of default branch. Kindly rebase and resend.