If writing, deploying, and maintaining this server doensn't seem like much work to you (and it may reasonably not be), write this server yourself and replace the pygmentize binary on your system with a lightweight client written in a language with a fast startup time that just calls through to the server.

Oops, I filed it in the wrong place, my apologies!

Doh!, I was looking at the jshint engine before, not the eslint engine. It looks like phab doesn't have built-in support for eslint yet. But this looks promising: maybe the autofixing eslint reports *is* on an error-by-error basis.

Writing, deploying, and supporting an additional service is an enormous amount of work for us and not a solution I'm interested in pursuing for this problem

(As a side note, the way we'd support this on our ubuntu phabricator machine is to write an upstart script to start the pygments server on startup -- it would also restart the server if it died -- and to run the server under pypy for even more performance happiness.)

Can you change the syntax to something like @unittest.skip("Reasoning behind this decision...")?

I know about T9853, but if there's still a chance you might consider merging that upstream, there are a few folks here at Khan Academy who are excited by the feature. Here's one example:

We've run into this same problem, but in the phabricator daemons. They also, apparently, run commands like:

git branch --verbose --no-abbrev --contains <sha> --

The proposed heuristic (different author and committer) feels pretty shaky, since if you rebase some of your own commits they'll have the same author and committer. I would guess this is somewhat-common in mis-rebases from master?

n/m, I see this was fixed today with https://secure.phabricator.com/rP1f2306999bb599bcedc0c4bfff2f2b3aade58630

Am glad to get ahead of it. What's the exact incantation we need to put into our php.ini?

(In fact, HostName seems to default to Host, so you could just do

Host phabricator-git.myorg.com
Port 2222

)

I didn't realize all the issues around munging urls in the UI.

Fair enough.

arc upgrade: Upgrade everything? This feels sort of bad/dangerous, maybe? But maybe fine? We could prompt?

D16149 has this code:

if ($tag_type == 'tag') {
  $this->log(pht('Skipping, this is a tag of a tag.'));
  continue;
}

Maybe the right thing to do is to check for != 'commit' instead?

Oh, I see I already made that suggestion! I am nothing if not consistent.

In the meantime, we could maybe do the following:

w00t w00t, I got something out of this bug report after all!

I don't have a shell alias, but I do have a wrapper script around arc. Doh! I totally forgot about that. Sorry for the false alarm.

Nope. I should have tried updating before filing this bug, sorry!

(I think I just repeated what avivey said, much more crisply, above.)

(But, and this is a slightly separate issue, it might be nice to have some indication in the 'default' section of which of those values is the current actual value -- maybe just highlight the value, or put a star next to it, or the text 'current working value' or some such. It's not necessary, and I know it will always be the first non-empty value that's marked in that way, but it would remove all ambiguity, especially in cases like the database has the empty string as its value, and a config file has a non-empty string, so the empty string is the default but it may not be clear from the UI.)

Yeah, I think just hiding the "value" section for non-editable controls would have resolved the issue for me. (In that case, I would have assumed the value was set to the first non-empty value in the "default" section.)

btw, I think the right fix is to have 'value' be the current value, no matter where it comes from.

I don't know where I'd look for documentation; where the excuse was I guess.

My apologies! I looked at that menu and somehow totally missed it.

This feature is a big hit over here at khan academy!

swisspol: what we do, which could be a workaround for you, is to store the private key in secret, and upload the certificate via /file. Files have access control as well, so you can limit access to the certificate. Then the description in passkey is something like 'Download the certificate at Fxxxx'.

Oh! I didn't think of hitting enter (I'm used to tab-completing instead).

Oops, my mistake -- the usage exception didn't reference Dxxxx at all. Instead, it referenced the differential revision of the change before mine.

Doh! That's the awsum.

Sorry, I've been having other phabricator fires today. And I changed my config to no longer import production.conf, so it's a bit hard for me to test it -- sorry!

Another possibility -- I'm not saying this is a good idea -- is to use unix groups. That is, have users set up a new "phabricator" unix group, and add the webserver and daemon users to that group. Then use umask to make sure that everything that the webserver and the daemons do are group-writable, and that they chgrp() to the phabricator group when starting up.

Ah, I understand; the existing links are the email client auto-linkifying for me.

Are you thinking arc diff + arc diff --browse, or just arc diff --browse which does an arc diff and then loads it in the browser?

According to the ionice man page:

Upon further experimentation: it happens even if I don't do 'git amend', but do a regular commit. Basically, if I do 'arc diff --verbatim' on an existing review, it always says 'D' rather than 'D1234'.

OK, understood. Thank you for taking the time to look into it! I'm glad that there's a straightforward workaround.

(If you do install the androvm emulator, the browser is the 'world' icon in the lower right corner at http://androvm.org/wp-uploads/2012/11/step6-359x300.png).

Yeah, if you don't have 'browser' showing up as an installed app for you, there's probably no way of getting it.

The default android browser is called 'Browser', and I believe is installed on default on all android phones (it's the browser used in WebView). My phone has a search bar at the top of every screen; if I type a query into that, it displays search results using the default browser. When I type a url into the search bar, it takes me to that page using the default browser as well. I don't know if your experience would be the same as mine, or different.

(That said, kitkat is replacing the stock android browser with chrome, and the text displays fine in chrome-on-android, so if you wait out the problem it will eventually go away. :-) )

I misspoke, my apologies. I'm actually on jellybean. Since kitkat is just now rolling out, and that in a limited way, I think it's pretty accurate to say I'm on the latest version of android. While I don't know for sure, I suspect that everyone who uses phabricator on android has the same user experience that I do. (If not, then it may be a problem with my phone in particular, though I don't know what that problem would be.)

Yeah, I don't actually mind the 2-up view -- I don't know what the 1-up view will look like, so can't say whether I'd prefer to use that or the 2-up view on my mobile device -- it's just the spacing. If magic meta tags could fix it, that would be da bomb!

It just occurred to me the problem may be the font used is not being downloaded or rendered on my phone properly. Not sure if that is my fault or not.

Ah, I think that would solve it indeed!