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.

When I add the dependency in the webui, I *do* get the diff-display behavior I want.

Sorry to complicate: My original assumption is that if I

For additional context, the reason we use arc diff <other commit> in our workflow is because we've configured git.default-relative-commit to be origin/develop. We're discussing removing this so that we 1) use the default behavior again and 2) encourage people to use arc feature so that branch tracking is set up in such a way that arc diff works as expected.

I use the same workflow. Manually running arc diff ${ other diff's commit } is a bit painful, looking up the other diff's HEAD commit and being super careful to pick the right SHA.

I believe there are cases where it is advantageous to have one revision with "A" and one revision with "A+B". I'm not sure what everyone calls it, but I've heard it being called the "git rebase workflow" before (versus the git merge workflow).

Something representing a prison, quarantine, or really good fence? I'm also a fan of the spooky ghost.

In T11284#184462, @chad wrote:

Can you give an example of what specifically you are trying to build in Phabricator?

@epriestley, just thought you'd like to know that, on that aforementioned massive task, the task names are now entirely missing. If you scroll all the way to the right, it shows the assigned person, and that's it. :\

Thanks for the analysis and the change. It makes a lot of sense to me now and, to be fair, I wouldn't have even seen the exception had the repository finished importing, which is what the fix does.
Thanks again.

Ahh, yeah D16234 was it. I'll make sure to update to HEAD next time. Thanks guys.

shruggy_ghost

haha i was just thinking the same thing with the spooky haunted file task.

Some kind of ghost would be good too, but not too snapchat-ey.