Sure, we'd be happy to accept a patch for this.

The project/global version of this ("Send an email to...") probably should not override user preferences. The user version ("Send me an email") is always user-controlled.

I guess you could try this? Maybe?

The order which we update repositories is deterministic enough that I'd expect things to usually end up locking in the same order, and they'll keep retrying regularly (every 15 seconds) after a failure, so it's not particularly surprising to me that the failures wouldn't be randomly distributed if the issue is a 64-character lock uniqueness limit, although I would expect us to see way more failures all the time since 64 characters ends before the callsign part and we haven't changed the lock name. Maybe the behavior is specific to your MySQL sub-version.

Does this patch also fix it?

Context on this:

Can you see if this fixes it (bringing lock name length under 64 characters):

It's also possible that this:

MySQL 5.7.5 and later enforces a maximum length on lock names of 64 characters. Previously, no limit was enforced.

Okay, that is the lock failing to acquire. Does this work?

Hrrm. Maybe wait for D12253 and see if that provides any clarity. It's possible it will give us a much better and more specific message, rather than just degrading into T6958.

Specifically, if that returns an integer, it's a connection ID.

Does this show anything?

More just that we'd like to reduce the number of config values we have, and we could possibly get this "for free" if T4103 has "global defaults for all available settings/preferences".

D12253 "fixes" this in the sense that it likely reduces it to T6958.

Never mind, I think that's someting else.

Oh, this might not be quite related.

It's vaguely possible that we won't need a separate setting for this after T4103, which is part of the reason I didn't implement it.

You can do this with Herald. Here's an example which prevents anyone but me from pushing to "master" across several repositories:

This is now live on this server. Notably, application help menus now show mail command help if the application supports mail commands:

That said, I can't reproduce at HEAD either, even with a substantial footer.

(To reproduce, you may need to have a footer which is at least 300 pages long, like WMF's.)

Oh, I just didn't read this correctly at all. Ignore me.

This is still frequently glitchy for me.

refers to the fact that you clicked the checkbox not being published yet

In the second case, "Unsubmitted" refers to the fact that you clicked the checkbox not being published yet. So this behavior is intentional, but not necessarily as clear as it could be.

Some possible evidence that this is confusing in practice rather than just in theory.

These calls:

We haven't seen any reports to that effect, and it seems equally likely that teams would be confused about arc exhibiting behavior which was not faithful to the underlying VCS behavior.

Mercurial records only one date, but the story is basically the same: we don't pass any special flags, and you get the same result you'd get if you ran hg commands manually. In particular, hg commit --amend and hg rebase do not update commit dates for the amended or rebased commits. If you don't like this behavior, you could try raising it to the Mercurial upstream. But we're respecting the underlying VCS and using the semantics which are most consistent with its interpretation of dates.

Git stores two dates, the "author date" and the "commit date". We update these in a way which is consistent with Git semantics (specifically, we do not use flags like --committer-date-is-author-date or --ignore-date to alter the semantics). The result is faithful to the result you'd get if you ran the same commands with git, and produces the values for "author date" and "commit date" which are most consistent with the internal meaning of these fields in Git. You can use "%cd", "--format=fuller", or similar settings to review commit dates.

I think we run the risk of running out of bandwidth pretty fast though. How do things work if / when that happens?

Yeah, I think there are two main issues here:

Like hologram stickers fancy?

If we adopt this, I'd plan to make it a public doc, yes.

I don't know if this would actually lower the barrier enough to meaningfully impact the kind of contract work we see, but it seems like it wouldn't cost us much to put this out there.

Very roughly, this is about two weeks of work so the cost to prioritize it would be in the $10K-$20K range. If that sounds reasonable, shoot us an email at contact@phacility.com and we can move forward.