In T4705#61706, @ott-consult wrote:

Yes, this would really be a useful feature. Especially as CentOS still uses a 5.3 version of sshd and on production machines, I would like to keep the "normal" sshd on the standard port. Using a different ssh port for all other tools require a lot of extra config.

Get a valid certificate or configure your system to trust your self-signed certificate. This is not a problem with Phabricator and I do not plan to support insecure SSL configurations in the upstream.

(I never tried to reproduce with Command + Enter because I always use Tab, Enter, and the symptoms seem identical.)

@joshuaspence, is it possible that this was causing the issue you were seeing in T10004?

At HEAD:

I think chunked files shouldn't have produced errors on reads -- at least, the --dry-run was still clean for me on both hosts before D14981.

Testing has been completed successfully.

Oh! Well that would make perfect sense, then. I'll update D14984 to just clear all the headers that remarkup can emit.

I'm going to merge this into T5155, since the root issue here is philosophical opposition to the use of IAM Roles to manage credentials in the upstream. Two possible pathways forward outside of upstream support are:

I've realigned this around support for IAM Roles, because we now use a first-party client after D14982.

In T10110#152970, @chad wrote:

maybe just hr and h2

This request does not describe a root problem. See Contributing Feature Requests and Describing Root Problems for help describing root problems.

Oh, the comment was a screenshot. Inline + width should work on this host now.

D14983 fixes the interaction between inline and width. I'll push it to this server and wipe the cache now, and the comment above should start working.

We should be in good shape to move forward here after changes in T5155. My plan is roughly:

See the Git documentation:

I do think we could reasonably put clear: both on hr and probably headers. I think it used to run into some problems with tables of contents, but we never (I think?) put them inline anymore (maybe in readmes in Diffusion?) so we should be in the clear, now.

Yeah. I think:

Wait this works now. Huh?

Points look great.

I'd like to put off building customization for as long as possible. I think we'll want it eventually to give custom fields broader support, but we can call all of that part of T418.

FWIW, here's what WMF's customized cards (by the Sprint extension, I think?) currently look like:

I migrated my development instance (~3,600 files from ~1 year of work -- I wiped the instance when we started doing instancing for Phacility circa Jan 2015) from S3 -> Disk and then partially back to S3 without any real problems, modulo an issue with chunked files. (Two files did error, but I found them in a different S3 bucket I'd used for testing a year or so ago.)

Dry run shows that some files are going to fail

(The case for doing this is weaker if it isn't for IAM Roles, but the S3.php thing doesn't support signature v4 (which AWS now requires in some regions) and the official SDK doesn't support older PHP, and having a first-party, future-based client will perhaps makes things easier eventually with T5544.)

Not at this time. This is far afield from our roadmap and we've seen little interest in it outside of your use case.

Can you just use an IP-based access policy instead?

I think there are two different issues with IAM.

Here's what I did locally. I wrote a rule to notify me about "dog" revisions:

Oh, I think this is because Differential doesn't fire Herald for comments.

Did your Herald rule actually fire? I don't see a step like "I looked at the Herald transcript for the revision and saw that it had fired, matched, and claimed to have forced delivery." in your narrative. That would be the simplest explanation.

You've created a subproject or milestone. You're strongly discouraged from doing this, and this won't work for a while.

Some of the older instances are beginning to collect enough data in MySQL to motivate this more strongly in the near term, especially as database data is currently stored multiple times on disk in backups.

Or, if I submit a 250GB wiki page, which behavior is better?

The specific case of renaming one top-level directory isn't really material. We could theoretically special case it (but perhaps not at a greatly reduced cost, because we must still distinguish between the case where you move the entire directory with 50,000 files and the case where you move only 49,999 of the files, and Git does not distinguish between these cases). That leaves many other cases (1-line change to many files, many new files, huge new file) which humans can not review but which users may run arc diff against, and which we must choose a behavior for. Our representation of this case is faithful to the Git representation, which shows each file as moved. A human can not review the raw linux.diff, and certainly can not tell if you actually moved every file or only moved some of them. If a human can't review git show, I think it's reasonable that they can't review the change in Differential either.

Is the diff so large that no human will ever review it?

Can we not also parallelize this with ExecFuture?

Why do you want to do that 41 minutes of work when you could spend 20 seconds typing the text "I am moving X to Y, is that OK"?

Why do we need to run git diff on files individually?

It looks like it's running a bit slower on your machine and you're diffing way more files. We need to run at least 50,000 git diff operations for those 50,000 files, so even if we magic away the rest of the work that's still 41 minutes (50k * 50ms per file). What behavior would you prefer?

No. Several organizations maintain private projects on this install which they use to express interest in various features to the Phabricator upstream and keep track of relevant changes and progress. One such organization is interested in this feature. It is now more likely that this feature will see the light of day, as it has a powerful enterprise backing it in some capacity.

If you run with --trace, what does the first 1,000ish lines of output look like?

I think all of this is fixed at HEAD.