Thanks :)

This seems to be happening consistently for all new commits.

When we migrate our repository hosting to Phabricator, I plan to setup multiple repository hosts for sufficient redundancy. In this case, I would expect the new hosts to clone the repositories from a read-only slave.

The steps to reproduce are quite simple:

If the repository is hosted elsewhere then Phabricator isn't the canonical source, and the other system would be responsible for data anyway.

The problem here is that things will mysteriously stop working. Let's say that I refer to rXabcdef in a comment and then later mark rX as archived and replace my repository tier. Anyone who later clicks on the rXabcdef reference will hit an error.

Even if that means data loss?

I disagree that this is the expected behavior, especially if this occurs on hosted repositories (which I can't confirm because I don't have any). If this occurs with hosted repositories, then archived repositories will be forever lost when replacing the repository hosting tier.

Yeah, either closing other open menus or allowing menus to be stacked on top of each other.

In T10323#158405, @chad wrote:

You sure this isn't a dupe?

This currently triggers autocomplete, but probably shouldn't: ` #f.

Yeah, I suspect that the length of the header is the issue.

In T9348#156791, @exp10r3r wrote:

I tried doing an arc diff to submit my patch but ran into this,

[2016-02-02 21:15:55] EXCEPTION: (PhutilTypeExtraParametersException) Got unexpected parameters: standard at [<phutil>/src/parser/PhutilTypeSpec.php:150]
arcanist(), phabricator(head=master, ref.master=3264d9f680cb), phutil()
  #0 PhutilTypeSpec::checkMap(array, array) called at [<arcanist>/src/lint/engine/ArcanistConfigurationDrivenLintEngine.php:90]
  #1 ArcanistConfigurationDrivenLintEngine::buildLinters() called at [<arcanist>/src/workflow/ArcanistLintersWorkflow.php:44]
  #2 ArcanistLintersWorkflow::run() called at [<arcanist>/scripts/arcanist.php:382]

I could run through it by removing the following section in .arclint file,

,
    "xhpast": {
      "type": "xhpast",
      "include": "(\\.php$)"
    }

But it wouldn't let me commit.

In T10269#156825, @epriestley wrote:

sorry that I can't provide reproduction steps

Historically, I don't think these tasks (error logs with no obvious negative effects and no reproduction steps) are very useful. I don't immediately know what's going on here, nor plan to dig into it unless it creates an observable problem.

Well I don't choose any tasks, I guess it defaults to all objects visible on the workboard (of which there are 865).

(This isn't a once off, there are a bunch of these errors)

The only issue that I've noticed so far is that @{article: triggers the autocomplete, whereas it probably should not.

From D15029:

Is it expected that this doesn't work on mobile?

Very nice.

Hmm, it is possible.

You can look up the PHID with phid.lookup.

In T8612#152820, @epriestley wrote:

Is the diff so large that no human will ever review it?

The scenario that I'm describing is not a large diff, by my definition. I would consider a diff which renames a single directory to be very small. I would expect a human to be able to review this type of change.

I am investigating a similar issue which a user reported on our install where a user is attempting to submit a large diff. I'm not entirely sure how large it is, but it caused cURL to timeout with CURLE_OPERATION_TIMEDOUT.

The timeout whilst submitting manually at /differential/create/ for example, is a terrible UX. We should at least try to detect that the diff is too large and will timeout so that we can provide a nice error message.

In T8612#152813, @epriestley wrote:

Why do you want to do that 41 minutes of work when you could spend 20 seconds typing the text "I am moving X to Y, is that OK"?

In T8612#152808, @epriestley wrote:

It looks like it's running a bit slower on your machine and you're diffing way more files. We need to run at least 50,000 git diff operations for those 50,000 files, so even if we magic away the rest of the work that's still 41 minutes (50k * 50ms per file). What behavior would you prefer?

In T8612#152810, @epriestley wrote:

Could we just push the commit to the staging repository (if one exists) and have the daemons parse the diff instead?

Sure, in theory, but it will take them at least 41 minutes to do the same work.

Why do we need to run git diff on files individually?