For completeness, T9953 / D14735 cleaned up an obscure rough edge on a narrow range of Git versions.

In T5554#134045, @jbeta wrote:

To make it still work out of the box with most potential users of insteadOf, we could use either command depending on git version if you think that's worth the hassle.

Implemented this approach in D13998.

In T5554#133958, @chandru wrote:

D13983 breaks on users running RHEL6. There git version is 1.7.1 and git 1.7.1 does not support --get-url option for ls-remote.

In those rare cases when I have to deal with "old version causes headaches, nev version is not avail everywhere", I put handlers for old and new in place, with handler of old way spilling out warnings that "old version causes headache and I don't care anymore about it, use new".

Thanks @epriestley. RHEL6 is still widely used, and even the latest update on that line carries only git 1.7.1. So if we need a new version of git, its installation becomes a messy business with either custom / rpmforge-extras repo or do compile/install. Would prefer if we can keep the 1.7.1 support around.

no one has ever reported an issue with an old version which we could not trivially resolve

It looks like --get-url was added in early 2011:

D13983 breaks on users running RHEL6. There git version is 1.7.1 and git 1.7.1 does not support --get-url option for ls-remote.

Those were all the cases of parsing git environment-dependent output I could find in arc (unless built-in formats like git log --format=medium are susceptible to git-config/localization/future change, which I doubt).

In T5554#133477, @epriestley wrote:

I think this tactic (re-run the command to figure out the error) is a really fragile one and would be very hesitant to pursue it over requiring users to install locales, but agree on this otherwise.

Yes, it would be a desperate measure with a lot of problems of its own.

the command has potential side effects, or the time of execution is important, and cannot be simply re-run under LC_ALL=C.

(Sorry I hadn't seen T7339, certainly makes my last comment mostly redundant. Perhaps the tasks can be merged?)

system default locale

Also not mentioned here is cases where we phutil_passthru() some command like git push. These would be best run in the system default locale, since we echo the output to the user -- unless we also parse it. I think we never do this right now, but I'm not 100% sure.

See also T7339, which is somewhat related.

I think the current Phabricator/Arcanist handling of locales, at least on Linux, is wrong. The LANG environment variable has lower priority than the family of LC_* variables, as per POSIX §8.2:

(This is a bulk edit test.)

I have this working functionally, but the UI is still an atrocious mess. Probably have something ready tomorrow.

After mulling this over for a bit while dealing with other stuff, I'm pretty convinced that the general purpose infrastructure in T5166 is the way forward here, so my plan is to move forward with that.

This appears to work to undo a status change batch edit:

Another report of this over the weekend:
the test in https://secure.phabricator.com/diffusion/ARC/browse/master/src/repository/api/ArcanistGitAPI.php;0c9a03771961be79d09e566051a5a594866760d9$503-508
fails for non-English git, which makes repo detection fail (And shows up as "you can't close this revision" exception during arc land).

LANG=en_US.UTF-8 should do the trick, but it fails if the en_US.UTF-8 locale is not generated/available.

At least for now, this no longer blocks Phacility or T2783.

T2783 is at least partially blocked on this, since I need to make intra-cluster calls as the viewing user and don't want to do handshakes. I also don't really want to ship session keys across in the raw, although that wouldn't be the end of the world. I'll probably push this about halfway forward and then drop it again once T2783 is unblocked.

I'm currently making the Phacility deployment tools load all Almanac services and filter them on the client to generate a list of instances hosted on a given machine (e.g., all instances with storage on db001). This is super gross:

D10895 appears to be a sufficient fix. I want to adjust some other keys on this table eventually so I'm going to leave this open, but I'll downgrade the priority once the dust settles.

All realistic installs with more than 100K rows should have 99% of them in queue.

Thanks @qgil

project.query does not emits the auxiliary dictionary, so there's no way of getting custom field value with the api :(

Another thank you note. You guys are great.

@austinstoker, you want to see this: T3179#81309

We want to migrate to phabricator from trac, but to get buy-in we need to migrate trac tickets and their custom fields to Maniphest tickets. As I understand we can either wait on this ticket, or delve into the code and try to resolve this. Is there any other option?

Great work @epriestley

There's also some kind of mess with MySQL 6.0 (which is 6 years old but doesn't exist since there was a transition to a "new release model" after Oracle bought MySQL AB?) and renaming utf8 to utf8mb3, and maybe renaming utf8mb4 to utf8. I haven't been able to figure out exactly what the story is here yet, but we should be well-prepared to deal with whatever happens there now that we have the storage adjust infrastructure.

Well, let's see if I destroyed everything before we celebrate too much.

If only beers could be purchased with mountain of wealth tokens... :3

I feel we owe @epriestley many beers and chips for this change. Or a lifetime's worth.

Closed by commit rPa17a36869254.

D10804 fixes the wiki issue directly. D10798 (which is the patch in P1415) will also fix it indirectly.

D10800 marks this as fixed. For more details (or if you run into issues) see T6485 (which will be updated shortly to reflect the current state of the world).

Also want to add that we had several duplicate differential_drafts on our install as well. About 15 objectPHID-authorPHID combinations had duplicates, ranging from 2-10 duplicates each. Cleaning them up was pretty straightforward.

No. See: https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#setting-expectations

Can this be implemented this year? Would be great present for Christmas.

I think some user has somehow managed to end up with two drafts for the same revision. The right fix is probably to remove one and then adjust again.

I'm getting the following error when trying to apply storage adjustments:

Yes, the current implementation doesn't pursue that optimization because it's simpler to omit it and simpler to debug issues when the queries only do one thing each.

Perhaps I'm misunderstanding, but it seems like storage adjust could be made more efficient. Each time you alter a table, MySQL makes a copy of it, alters the copy then replaces the original with the modified one. If we perform several alters, this adds up to several table copies. On large tables this takes considerable time.

if I export myself LC_ALL=C it just works.
don't know why it was failing from the patches you have provided me

We can not parse every language. In the very narrow case of patch files, we probably can, but we depend on parsing the output from many other commands to detect specific errors in all of Git, Mercurial and Subversion. For example, sometimes a command exits with, say, exit code 1, but several different errors can actually cause that exit code, and we want to act differently depending on which error occurred. The only way we can tell which error occurred is to look at the program output. To parse error messages in every language we would need to hard-code every translation and keep that list up to date, which is unreasonable.