Very soon now, git is getting an exciting new wire protocol. Highlights are improving performance on repos with unholy amount of refs, and being "easier to expand".

In D19455 I've reduced our "enormous change" threshold from 1GB to 256MB, which puts us underneath Git's 512MB magic number. This probably mitigates this to at least some degree.

The companion "provide more guidance" patch would be something like this:

This is involved, and default_authentication_plugin=mysql_native_password doesn't fix it.

When comparing diff 1 to diff 2, hide all files which have not changed [and have no {old/right/undone} inline comments].

An adjacent issue is that the actual connection exception doesn't make it up to setup guidance. It's somewhat tricky to raise it through the stack since the mechanics are substantially delegated to a bunch of cluster connection management, but we should make more of an effort to get it up to top level.

In MySQL 8.0.4:

Mercurial 4.6 has added hg help internals.bundle2 which will render a book to your console with details about the format/protocol. I did a high-speed skim and then tried out hg help internals.changegroup on a whim which produced an even longer book about the stream protocol (SSH only maybe?).

I added a linter and I accidentally included this line which references a different already-existing linter

final class ArcanistChmodLinter extends ArcanistLinter {

D19442 is marked as fixing this, although it just raises the limit from 80 to 100. This span measures the number of characters between the first changed character and the last changed character (not the total number of characters on the line) and we haven't seen tons of interest in this over the last several years so I think few installs are running into issues with it even at 80. Bumping it to 100 should give us a bit more breathing room but I don't currently plan to make it configurable (see T8227).

An install would like a way to filter commits by a particular branch, plus normal filter criteria.

Some of this moved forward to T13137.

I like that reasoning a lot better than mine, and simply omitting type appears to produce the correct behavior in every browser, at least for this file. I'll try that instead, and we can revisit this after we write a video transcoder in PHP and can offer files in multiple formats.

My knowledge is centred around broadcast video / IPTV (UDP multicast) rather than HTML5 video, but that seems fairly reasonable. I don't think anything should try and download the file twice unless it is a complete clownshoes implementation that probably has multiple other serious bugs wasting bandwidth. I think the worst case with no type that might be hit here is that the browser could decide to download the entire file on load to figure out the format and duration, rather than starting with byte-range requests, but this is easy to test and unlikely (I'd expect any sane one to always request chunks).

I can imagine that two <source /> tags might, in some bizarre world, cause browsers to download the file twice when you click "Play", if they're super confused about how to process videos, don't notice that the URLs are the same, and don't hit any caching. But that's a pretty minor bad effect, and I didn't immediately see any kind of bad behavior locally.

Thanks! I wouldn't mind parsing that but I'm hesitant to ask installs to install it -- but it's helpful in understanding that I'm not completely crazy here and that there's at least some basis for "video/mp4" being a quasi-legitimate way to label the video file.

mediainfo is the tool for this, but is really overkill for programmatic use.

One easy approach we could take is just:

An install is hitting the "large blame does not degrade gracefully" issue mentioned in that task