In D12577#192669, @Alphare wrote:

I personally find this harder to read since you have to distribute in your head. -0?

I'm not very tied to this, if someone thinks this makes it worse, feel free to reject.

In D12424#190106, @Alphare wrote:

Unfortunately, zstd > 0.5.3 does not support our minimum version of Rust which is 1.48.0. I'd already tried updating, but this'll have to wait until Debian stable updates (or someone adds back backwards compat, which I doubt).

In D12371#189448, @Alphare wrote:

Looks like this breaks the code formatting tests, and the patch has been published so I can't amend it. Please send a follow-up I can queue

This really feels like a bug that they're advertising support for xterm-compatible escape codes, and then not setting everything up to handle it properly, but for all I know it's not possible for them to do so (i.e. maybe Windows requires that each Process enable vtmode for every Console it cares about, it can't be done "for us" by these tools)

Should Flag negation be rare ?

I disagree here. We should use clearest available verb for flags, using negation to get the meaning we need. I would draw a similarity with boolean naming in the code, where we don't have a preferred "default" state for the common case, but we phrase the boolean in a way that is easy to read.
In addition, having a mix of negation and non-negation as common case will help make the (negation) feature more discoverable.
What's your rationale for wanting them to be rare ?

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.