I do discourage it, but I was using italics to highlight the difference, which is pretty delicate.

In T11121#179831, @julioromano wrote:

Your usage of italic makes me think that perhaps tagging practices like
this are to be discouraged. Is this the case?

Your usage of italic makes me think that perhaps tagging practices like
this are to be discouraged. Is this the case?

If that herald is blocking your push, it means you're pushing new commits, not only new tags.

That's what we've tried to do so far, but the git push tag command is being
blocked by our Herald rule because there is no approved differential
revision associated with that push.

T10329 is likely also related if you really want to do what you've been doing so far.

In that case, you should create the tag when you release, and only release from code that was already pushed, not from code that is "about to be pushed".

We'd like to use them to tag releases.

This should probably be a Ponder question (See Support Resources).

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

Config → All Settings → phpmailer.smtp-encoding

How can I enable base64 encoding within phabricator?

Let's just make base64 the default and see what that breaks. ¯\_(ツ)_/¯

More specifically, I believe phabricator is violating the RFC when it sends overly long lines and that postfix (or whatever is munging the output) is taking a rather silly action as a result.
base64 encoding the output should work around the problem.

From RFC 2822 There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
I believe the behavior of splitting the lines using a ! is implementation specific.

If your email goes through postfix, it breaks lines after 1000 bytes, rain or shine.
The solution I got from IT was "Set phabricator to encode the mail using base64".

The client was thunderbird and the webclient (based Open-Xchange). I received it on my personal mail account, outside the company.

Received: from giant.haxx

It's expected that the ordering in "Browse" is alphabetical/raw, and I don't plan to change that.

Interesting. The same mail was delivered to me intact:

Here's what happens when adding wikidata project tag using the comment form typeahead:

Here's the mail that I received for your comment. You can see that the M stream is broken with "!" in two places. This seems to match the behavior I observed initially, although there was also an extraneous blank.

• We currently use white-space: pre-wrap to handle linebreaks in prose diffs, but at least one client (Airmail) doesn't handle that properly. We could use explicit <br /> to improve behavior.

I think this should work now. I tested it locally with HTTP and SOCKS proxies via Charles and those both seemed to behave properly.

I have commented out internals of entire function that contains apc_sma_info() request and everything seems to be working fine :)

Sounds good. I'll call this done for now, let us know if you run into issues.

Thank you. We will upgrade this weekend and report back.

Your versions above are over a year old. Sorry for not catching that sooner.

We don't support old versions of Phabricator. Per documentation we require all bugs and support requests be performed with a current version.

I've read through this article and I am unable to determine what the next step should be. I've already used the repository tool to reparse the bad commit but new commits all go into the same state. One thing to note, my version of the repository tool does not have an --importing flag.

https://nylas.com/

All the cool companies use Phabricator.

I should switch to Nylas since they use Phabricator.

I was able to filter by status using the queryKey, which is much more valuable than displaying the status. So omitting status from the response is ok by me considering the level of effort required to refactor the numeric constants. Thanks again, much appreciated!

Airmail on Mac, it has a few quirks with our HTML emails, but I haven't tried to debug it yet. I'm sure we're doing something weird since all other HTML seems fine in it.

I think we're relying on white-space: pre-wrap; right now. We could explicitly do \n -> <br /> conversion which might fix newlines, at least.

Which client do you use? I imagine the html relies on <br> or something, but would \n vs. \r\n be involved at all?

maybe by 2050 email will work most of the time for most people

I use a crappy email client

The actual diff is further down and rendered correctly for me, at least -- that's just how we currently render "added one line to the middle of a 500 line document" right now:

No, that's this stuff from T7643#179240:

I got a super long email from Phriction today, is that also an EditEngine freebie?

I'm leaning toward exploring this in the near term. We have four applications which may convert soon:

Oh, one more thing:

I return the other fields, but don't currently return "status" because I'd have to return an internal numeric constant. So we may need to fix that more thoroughly before you can move forward.

Awesome, thanks for the quick turnaround. This looks good to me. Currently I'm using revision ID, title, status, and authorPHID in the response for display purposes. I'll try your recommendation for 'open' revisions using the queryKey to handle the status.

Actually, this is slightly more involved because you want to select open revisions.

https://secure.phabricator.com/book/phabricator/article/repository_imports/

https://secure.phabricator.com/book/phabricator/article/support/

You essentially only need the revision IDs in the response, right?

I created the task, then changed the tags manually (selecting only the tags I felt necessary - also removing the BUG tag). Seems I may have found a bug with the bug tracker. ;)

That is, if you go to the Diffusion workboard, we give you a generic create form instead of a choice between the various normal create forms, currently.

You can file stuff without those tags from workboards, and maybe "Support Request" just got caught in the crossfire of typing every possible tag, so that's a legitimate-albeit-unusual pathway here. But I wouldn't expect the short-lived "New Support Request" form to be accessible any longer.

This tracker is for bug reports and feature requests, and we're surprised you were able to file something without either of those tags.

How did you file this task?

After D16088:

(assume you mean to post this on a different Phabricator)

We haven't seen other requests for this and it's consistent with the similar behavior in Differential.

This should also fix the mobile workflow stragglers from T2644.

I have just tried ubuntu 16.04 LTS with php 7, apcu and apcu-bc and i can confirm that with apcu enabled there are issues with php random crashing with "zend_mm_heap corrupted" likewise T10987

Anchor tags got cleaned up in D16083.

This report doesn't include reproduction instructions and doesn't clearly demonstrate a problem: all of the screenshots are explicable through user error.