It could help a lot to not only say the return code is invalid, but also display its value, and stdout and stderr.

Beside !requiretty i've defined also umask settings to enforce group-readwriteability of repo files.

Thanks for the fix :)

I think I broke and fixed this doing some related work in the area as I did all sorts of things to the low-level transactions framework around when this was reported.

@hcordero: As Maniphest is for tasks and as this seems to be a support request, please refer to support channels for any further followup questions.

The community hangs out in the Phabricator channel (type # and phabricator as one string) on irc.freenode.net

What are your specific settings? (It sounds like an issue with how you've configured your mail, or issues with SSL or your mail server timeouts)

I think we'll pass on this for now (since we have no means of prioritizing it without a concrete path). It is something in general though that we've discussed for Fund.

There is no "problem", in my case just the idea to add some badges to "award" people that use Ponder (with a complex logic of points given based on number of questions, answers, like, dislike, frequency of use, etc.)

Can you cite this request into a more concrete problem you are having with Phabricator?

Should be fixed if you update to rPb718b429afc61796475cf537b7623c6c7b9c48ae or later.

The problem went away as soon as I updated.

This is intentional.

Yup, thanks!

I presume this was resolved in D10935, but will keep open if not.

Update Phabricator

Related, the actual summary the UI box gives me when the exception is thrown is:

Oh cool. I've updated and will report back.

I'm actually not seeing this issue any more after updating.

I haven't triaged this but it sounds like it may have Support Impact.

There isn't enough information to reproduce this issue. See:

We're experiencing this problem and it's quite severe. It's causing commits to show in diffusion as "still importing", and it's preventing autoclose from working. We're seeing these very frequently.

Some possible approaches here:

See T6583 for discussion.

In T6616#85112, @epriestley wrote:

Assuming locale compares work in a reasonable way, it seems like they should be more correct.

For example, as an English speaker, I expect strings to sort from "a -> z". Even if I'm viewing Australian strings on an Australian install, it's still better for me as a user to see an "a -> z" sort than an Australian "z -> a" sort of the strings, because it's one I'm more familiar with.

I do get a better result for localeCompare() than for < with Ł, in English: localeCompare() correctly puts it between "L" and "M". This is where I'd expect it to appear as an English speaker, and presumably a Polish speaker searching on an English-language install would still prefer a colleague named "Stanisław" to sort between "Staniskaw" and "Stanismaw", not after "Staniszaw".

We don't have any current plans around skinning, though we will progress to allowing some minor branding replacement over time.

One issue with using dotless domains is that Chrome will not be usable at all, as it does not save cookies.
This is also why this check was originally implemented, to prevent dotless domains; see https://secure.phabricator.com/T754#7045

https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#common-fixes

I edited the above to remove an erroneous discussion of sorting "ë" -- I just misread the output.

Assuming locale compares work in a reasonable way, it seems like they should be more correct.

I don't believe it's intentionally inconsistent, just that it was added as a convenience and things no one thought of were not tested.

But why make it inconsistent?

• It loads the content if the user clicks with the left button (in the same page, even if CTRL is pressed)
• It does not load the content if the user clicks with the middle button (the callback to JX.Stratcom.listen('click', null, ... ) is never called).

I understand what you're saying, but it was the intended design when I read the comments. The offending code is at https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/js/application/aphlict/behavior-aphlict-dropdown.js;12f3f6d3a9ef9c7731051815846810cb3c4cd248$87 if you're interested in supplying a patch, we'd take a look at it. Overall it'd be hard for us to provide this feature in any reasonable timeframe given it's relative impact.

Try cliking in the empty spaces instead of cliking in the links.

I am not able to reproduce this on Firefox 33 / Mac or Windows. We just use plain old anchor tags there, nothing magical.

I tried submitting a patch and it seems to have worked, so I guess I could "claim" this…?

We are not interested in this solution in the upstream. Onboarding is an issue that will get resolved separately. We don't like to build things that support issues found at only one or two installs, and prefer to solve the bigger issue that affects everyone, which is most likely onboarding and understanding all that Phabricator has to offer.

This can easily be solved by a simple compromise. When disabling the 'UI levity', also switch the primary interface labels to show generally understandable counterparts such as Tasks, Wiki, Code Review, Continuous Integration, UI Mockups, etc. :-)

Keep the names, they are great, it is the UI and onboarding process that is confusing. This amounts to repeated struggle while each new user has to grasp the idiosyncratic naming conventions.

This functionality exists already, though it is more recent. Please update to HEAD.

This request comes in every few months. The vast majority software in the world is 'creatively named' and it presents no actual problem (Chrome, Wordpress, Powerpoint, Photoshop, etc). There is a lot to learn to become proficient with any productivity software, and learning the names is very, very minor. Not to mention we already have issues with "Projects" which confuses people since the term covers more than just 'software projects', but also teams and policy containers.

Well, actually, PhabricatorMetaMTAMail already implements an HTML view.

I don't like the cost to have to add an HTML counterpart to the mail. Even if Gmail will print plain text mail if such preference has been set (I receive my GitHub mails as text) and will still add the notification from the HTML part, it's like an hack. So I'm rather reluctant to the feature.

Closed by commit rPdc1106a9b910.

It worked! Closing.

It worked here! Closing

I replied to your ticket on Github.

(Genuinely curious if the header resolves this, let us know). Going to close as wontfix, don't see any easy way to warn and generally not interested in some super complex browser detection.