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.

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.

One easy approach we could take is just:

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

See PHI594, where a real user had the same human name as an external user from another project.

From PHI604, for completeness, on the newer behavior of "Hide Blame":

validation for the configuration option

Just to make sure we're talking about the same thing, that feedback is true even of the version at HEAD (blue/grey/orange) vs the version that originally shipped (green/grey/red)?

I think there's possibly at least some argument that this element could serve noble goals:

I suppose the approach proposed above gets a questionable result here:

After actually looking at the code, it looks like null can already be returned and works, it's just kind of wrong for some objects (like Dashboards) because they really do have a default policy -- it's just hard-coded.

See PHI612 and elsewhere; using "Take action [the first time this rule matches]" isn't always obvious but is usually a better fit than "When [ thing is created ]" and interacts much better with drafts.

A 600MB patch should not take 3 hours to encode. We should reproduce this and fix whatever the problem is (buffer appends or otherwise), or clearly document why we actually can't fix it.

I'm going to tentatively put this (the Phriction rule, specifically) into T13130 for this week although I'm not sure how much work getting getDefaultPolicyForObject() to return the root document policy is and maybe that's Unbelievably Difficult. Let me take a quick look at that and you can either run with it or I can pick it up if it's some kind of weird arcana.

Ah, yeah. No idea why I typed "blind" instead.

One option is to write "Herald Rules for Herald Rules".

Offhand, two possible issues with that:

See PHI580. An install would like write API access to object relationships (depends on, fixes, etc). This is complicated, but perhaps plannable, and we may be able to put a reasonable facade with partial support into the upstream.