Committer identities ... they're currently stored in a JSON blob so there's no efficient way to query them.

That was sufficient to get what I needed, thanks so much.

Is there a way to find which object(s) an (unmapped) identity was discovered on?

Is there a way to find which object(s) an (unmapped) identity was discovered on? After a rebuild-identities, I have an empty string identity and a couple asdf-style garbage ones. I'd like to find the source of them and either fix them there or see the context to understand the appropriate identity mapping.

See https://discourse.phabricator-community.org/t/data-truncated-when-pushing-into-repository/3586/ for what is likely to be a related issue.

Perfect; thanks!

In the general case:

Sorry if this is a stupid question, but now that this is done, how do I actually map between Phabricator users and VCS user strings, in an existing Diffusion repo?

I think this doesn't have anything actionable left, see T13444 for some followups. This feature probably isn't 100% perfect quite yet, but I think remaining work is just cleanup.

In T6722#197239, @avivey wrote:

I think a more powerful approach is to support some kind of "templates", so that we can create a new "Android App" repo or "COM Module" repo directly, similar to how IDEs have project templates.

I think this is effectively resolved by T13277.

See D20419 and T13277.

I would like to add another use case where this would be beneficial.

Piece by piece, this was effectively untangled. Differential largely moved forward; Arcanist has a path forward in T13098 (although it's ultimately a "major version" sort of change), and Diffusion stuff has settled into relatively actionable plans in, e.g., T13075.

I did rebuild-identities on every instance

The "activity" migration went to production just now. I expect all production instances just bailed out, since I ran rebuild-identities some time ago, but I'll verify that:

In T12164#239595, @mydeveloperday wrote:

just wanted to give you some reference data (your mileage may vary), I have 2 Phabricator instances with multiple git repos

one has ~300,000 commits ( a mixture of read-only (mirrors) and hosted repos), the other ~200,000 (all hosted)

in both cases I ran rebuild-identities after doing the Week25 upgrade

time ./bin/repository rebuild-identities --all

it took

21 minutes on the one with 300,000 commits and
16 minutes on the one with 200,000

Can't help but think that this was most likely limited by the speed of the terminal output.

Hope that helps others

just wanted to give you some reference data (your mileage may vary), I have 2 Phabricator instances with multiple git repos

I deployed D19484 and db010, db024 and db025 finished up with no issues.

These hosts ultimately timed out on the initial rebuild-identities: db010, db024, db025.

From T13152 -- none of this is too important, just didn't want to lose it when I close that:

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

D18988 addresses the issue from D18105 (git grep 🐑 fails) more directly by calling @setlocale(LC_ALL, 'en_US.UTF-8') unconditionally during startup. The motivating case in T13060 is:

This is resolved as far as I'm aware. See also T11767 (improvements to these limits), PHI125 (similar issue with non-UTF8 attachments failing to insert) and T13053 (planning).

With T13001, the commit page itself now gives you disambiguation options if the commits are in the same repository. This is a narrower case than ambiguous commits across multiple repositories, but related if we did pursue something like hovercards or a multi-repository disambiguation page.

Another approach that might make sense would be to highlight the hash and then show a hovercard which lists the commits with that hash. Of course this wouldn't scale too far but it should handle the case where 2 or 3 commits have the same hash.

In T4369#232848, @epriestley wrote:

I don't see any easy way to cheat through $_FILES, though. We could remove it, but we have a nonzero number of users who compile their own copy of Linux and use a window manager that doesn't support drag and drop and disable Javascript and don't believe a monitor should ever have more than 256 colors, so that would leave them out to dry. The conversion also isn't trivial, so even if we want to move in this direction eventually I think it's a significant scope expansion over just building a synthetic $_FILES.

Our access to superglobals in PhabricatorStartup comes from D6672, and works around an issue where PHP's (fairly insane) sanitization filters are configured.

Would auto_globals_jit help?

When enabled, the SERVER, REQUEST, and ENV variables are created when they're first used (Just In Time) instead of when the script starts.

A wrench in the gears here is that disabling enable_post_data_reading also disables $_FILES, which we use in about 20 places with vanilla HTTP <input type="file" /> controls. So on top of initialization order issues with $_POST, we also need to build a multipart/form-data parser that can populate a synthetic $_FILES or some similar construct.

Oh, yes, sorry, looked at the wrong tab.

Do you mean "follow up in PHI55"?

I'm going to presume this is resolved by D18598 -- I updated T11767 with more plans and context for smoothing over the behavior, but I think it will no longer be disastrously bad. I'll follow up in PHI36 PHI55.

For hg, set HGPLAIN=1 will disable translations. See hg help scripting for details.

This accidentally got fixed this week

Isn't that a dup of T8611?

Presuming this is resolved since it's extremely boring and I ran it here and on every instance in the production cluster last week without any issues, but yell if you run into problems.

I see, it must be a text file.

Safari / OSX:

word-break: break-all; seems to be working fine.

I can't reproduce this, is there a specific browser/OS I should test? Also, feel free to upload a test file to rGITTEST