Anchor tags got cleaned up in D16083.

This report doesn't include reproduction instructions and doesn't clearly demonstrate a problem: all of the screenshots are explicable through user error.

We haven't seen other requests for this in many years.

I can't reproduce this at HEAD, presuming it was resolved some time in the last year.

After a little thought, I'm leaning strongly to putting every schema on every database. I think this makes a lot of the administration, maintenance and implementation easier.

Here is a string of 2048 unbroken "M" characters:

Oddly, in the prior case where mail was mangled for a user on their install but similar mail was not mangled here, the unmangled mail I received was encoded in "8bit", which tends to suggest that this might be an MTA problem rather than an "8bit" problem, per se. But changing the encoding away from "8bit" might be the only real lever we have to fix the MTA.

The trigger for the behavior is likely just "long lines of text", we had an earlier report of something similar occurring inside an inline comment snippet (but it could not be reproduced on this install).

It's possible that adjusting phpmailer.smtp-encoding (say, to binary or base64) might fix this.

I implemented this, sort of. However, it doesn't work cleanly because transactions are "adjusted" (have old values populated) after they are "expanded" (which generates the @user mention transactions). So when the code runs, it doesn't have access to the old text and can't easily figure out which mentions are new.

Particularly helpful would be to write some comment on this task which reproduces the issue for you, then tell me which client you're using.

There are no plans to implement this for Git. Git has had robust history rewriting for a long time.

Can you try this?

This will vanish for free when we move to EditEngine, or it could be special cased before that by either:

This one feels a bit un-human-like, although it might be tricky to fix:

I think that's fixed in HEAD now. I pushed it here, let me know if you catch any cases which still misbehave.

Specifically, the issue you're hitting is that [[ x#y ]] and variants thereof generate garbage output?

Yes, this is probably pretty straightforward to implement by mostly copying Maniphest's implementation.

This has been live for a while and appears to be working properly. If anyone is still seeing specific, reproducible problems with cache strategies, feel free to file a new issue detailing them.

I think it's probably correct to fail with --skip-binaries, but it would be nice to preserve that metadata through the process so arc patch can warn you about it, something like:

I think we're good on the actual Phacility flow, seems like users aren't running into the same problems they used to (e.g., confusion about ""test" instances").

It would also be nice to develop an inline version of this for title changes like this:

In T11047#179388, @grindhold wrote:

maybe it would be an option to at least identify lethal arguments for commands and warn the user if he enters some. like rm does when typing rm -rf / without --no-preserve-root.

For completeness, T11107 was also related to this.

Can you file a new bug with reproduction instructions? That isn't expected.

This isn't a use case we're interested in supporting. Phabricator creates the repository in a well-defined location, not a random location.

That isn't a usable root problem description, you've just restated the original feature request.

This creates a problem for absent-minded or new users:

When filing a feature request, we need you to describe your root problem, not just ask for a feature. See Describing Root Problems for help.

I think I figured this one out: it's actually because more than 100 rooms are being filtered. The (`id` < 367) part is being added by pagination code, but won't activate if a user is in less than 100 rooms.

We should fix these, but I think these are fairly self-evident and I think fixing them isn't trivial since I recall declining to fix them the last time I was in this code.

I'm not sure I understand the use case for that. Do you set your client OS to local time, but prefer to use Phabricator in UTC? Offhand, this seems unusual. Do you have any particular reason for doing this (e.g., you live right next to a timezone boundary and change zones multiple times per day)?

I added you to Community, so you should be able to make edits yourself now

Yes, but why?

Specifically, you saw this page, and decided that you were not in the right place?

This should be resolved at HEAD of master. To get it to work you may need to update and then go through the password reset process again.

I'm sure there are still some cases where we don't do a particularly good job, but let me know when you run into them.

I think this one works:

I have no idea if this is MP4 or not:

I'm going to merge this into T6916. That implements a reasonable behavior for application/ogg (assume video by default, allow users to embed as audio instead with media="audio") and browser seem to do fine when audio is embedded with <video /> anyway, so I suspect we'll be in reasonable shape after that and not need to try to determine the contents of OGG containers in a more sophisticated way.

Diffs should be less choppy now, here's the improved version of the above change:

Great, glad things are working now. Thanks for confirming the fix!

I think this pretty much boiled down to three technical pieces, all now better covered elsewhere by more specific tasks:

This is pretty rough (particularly, the actual diff part), but wired up everywhere. HTML email includes a link:

Well, I'll leave this open for confirmation/feedback/etc.

Here's the new AuthProvider code for OAuth2 autologin after D16060: