We can revisit this later if use cases develop, but we haven't seen any need for it yet.

This is on EditEngine + Modular Transactions now. There are probably still some remaining issues I didn't catch.

I've marked D16287 as fixing this, although it does not fix Countdown (today, only Calendar has the new behavior).

Sounds similar to T11092, which was recently resolved.

Needs a check for empty and at least a better error message in DiffusionBrowseQueryConduitAPIMethod.php:115

We are seeing this as well when attempting to browse an empty commit: https://phabricator.wikimedia.org/T140236

I'm unable to reproduce on a test install right now, but then again, I stopped reproducing on my install after rebooting the server. It looks like something happens eventually to cause this to break and I start getting these broken comments.
Looks like every time I get a broken one it doesn't have a transaction PHID associated with it and all comments submitted together have the same wrong associated commitPHID.

oh neat!

You can use a free instance at http://phacility.com/ if you need a clean, up to date place to test privately.

This is, by the way, on a brand new install that's not even a month old.
I tried to reproduce it on another install that is older and I'm not having any luck.

This actually is a lot worse than I originally thought.
All inline comments that are made on an audit are actually applied to the audit I was previously commenting on (like an off by 1 error). I've isolated the following things:

• This happens across repositories (i.e. if I have multiple repositories, commenting on one commit and then switching to another repository's commit and commenting on it will produce a comment on the first commit)
• This happens for all users
• This happens regardless of audit status - i.e. commits with audit requested exhibit this as much as commits that don't require audit.
• Submitting an empty comment first thing before adding any content to a commit works around this problem - subsequently added commits appear as expected.
• The broken state can be easily detected by unavailability of the "hover state" of the overall commit field - pressing "z" does nothing

(Presuming that fixed things until we see evidence otherwise.)

I should add that their plans for mid-2016 is to integrate all of this Windows OpenSSH support into the OpenSSH upstream repository, which is likely to be the time that Microsoft declares it production ready.

In T10203#185542, @thoughtpolice wrote:

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

Yeah, Appveyor only supports one concurrent build, but that's *more* than OK for us now, at least. Any form of CI on master and our STABLE branches, at least, is better than no CI for Windows.

Indeed, fixed.
You guys rock!!

Specifically, this should be resolved by D16242 (July 6).

Can you update Phabricator and re-test? I expect this to already be resolved.

T11319#185560 has some additional discussion about somewhat-related-ish issues.

It might be reasonable to un-pht() the field names in the short term until this gets solved for real, although it would be nice to see a use case with a legitimate translation rather than Pirate.

This is sort of very vaguely related to T5586, although I don't know if the fix will end up being the same or not.

"Spies" should get picked up and parsed as "Subscribers", just like "Fixin'" should be picked up and parse as "Fixes".

We tend to combine similar issues into one so they are resolved at the same time by the same diff. The correct solution I believe here is the same as "magic words". That we need to maintain a list of words that are localized that trigger actions. "Spies" should get picked up and parsed as "Subscribers", just like "Fixin'" should be picked up and parse as "Fixes".

That's correct, there are no magic words in my diff message. The template I'm given when I create a new diff contains text (I assume because of the Pirate language setting I've chosen) that causes Arcanist/Differential to choke when the message is committed, as "Spies" isn't a valid heading in the Diff message.

I don't think this is about "magic words" - those are things like Fixes T123. This is about "regular" l18n: Differential is producing a form it can't read.

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

Alright, that's promising at least. Thanks for testing!

In T11291#185175, @epriestley wrote:

It's possible that we're in the wrong by falling back to set character set utf8;.

For anyone who can reproduce this, does this fail?

mysql> set character set utf8mb4;

We could also possibly just drop these commit mails in all cases where no audit triggered. It's easy to write a Herald rule to restore them if you do want them. Possibly involved enough to be adjacent to T10978, though.

A small part of the motivation for this change was to make commits reachable only from Gerrit magic refs (refs/changes/..., similar to refs/pull/...) visible in Diffusion. This didn't really make it into a single upstream task I think, but some of this is scattered across T9726 / T6878. So we have at least one use case where users want these refs to exist and be treated roughly like they were tags/branches.

I do think there is significant room to improve the behavior of arc diff (roughly captured in T6072) but I'm ultimately not sure how to improve this situation:

Yes, writing "Depends On" in a commit message or editing "Edit Parent Revisions" or "Edit Child Revisions" in the web UI should never affect what is shown in Differential. If you can reproduce this, this is a bug which we'll fix.

Please see Planning for information on timelines.

It's been 2 years since this task was created ( my company isn't able to use Phabricator because this functionality is missing ). Do you have any update on current situation ?

All your ghost are belong to us!

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

If it becomes a persistent problem, we will update the documentation.

Do mention that on https://secure.phabricator.com/book/phabcontrib/article/version/ .

We don't have the capability to support every user who uses Phabricator to file bugs directly into the upstream. Users also don't have the means to update their local instance before filing a bug, which we require (we only support the latest version of Phabricator). Users can also use http://phacility.com/ to reproduce bugs.

Maybe they can get it out of one of the HTML comments inside one of the pages.