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.

The webmail client allows me to view the raw mail. It's malformed as well.

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.

bin/mail show-outbound --id <id> --dump-html shows the mail fine.

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?

for us repository.default-local-path is set to /percentile/source/working/
Just created a new repo caled test7 and it set the storage location to /percentile/source/working/105/
I'd call that pretty random.

As an alternative to Luke081515.2's request for an option, I just filed T11118. This would also allow an easy return to the old behaviour of always triggering audits, regardless of who the author is.

Click "Try Free" then click "Test Instance" after signup.

$20 to use Phacility?

I'll re-test on our private network w/ latest phab soon, who knows maybe it's fixed.

All I needed to test on my home comp's ie as well was access to a 6 column workboard here, but I felt paying 20$ to use phacility was a little steep to keep the bug open.

im gonna do this task. im gonna do it up real nice.

Any individual tasks here left to do separate from T9303?

T5317#64279

Can't find a means to reproduce this locally and haven't seen other reports. Can revisit if either of those change.

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

This would be a massive workflow improvement for us

O.o

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.

Yes. [[ x#y ]] or [ x#y | some text ] results in a link to /x/#y/ which doesn't actually link to the anchor.

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

(broken wiki links everywhere)

+1 we just discovered this issue and ended up here

@davidism You probably don't want to be posting full memory core dumps publicly.

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

@epriestley I assume application emails are abstracted like Maniphest?

OK, thanks!

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:

@hach-que can you disable php-apcu from the phabricator install, or do you mean to comment it out in the php/php-fpm config?

Can confirm this on another instance with the same package versions as what is reported in original post (Arch).

Closing this out since I don't think this is something we'll want to pursue (less flexible workboards).

Anything else we want to do here?

We don't officially support localization, though you may use it if you feel adventurous.

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.

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.