In the very, very general case, I think it's undesirable to favor "N" over "U" because the reports could be coming from two different engines, only one of which knows how to execute the lines.

I added you to Community if you want to do the honors. :)

I can't immediately reproduce this, here's what I get:

Since only the first connection has an issue, you could also conceivably add a slightly-more-than-one-line patch to make arc land run some no-op remote operation (git remote show origin?) and then immediately kill the subprocess, creating and throwing away the bad connection so the followup doesn't hang.

If you're open to patching one site, you can just comment out the feof($stderr) to retain the bulk of the change (i.e., still wait for stdout).

I can sort of see arguments either way, although I think I'm inclined to names too.

Change milestoneNumber in phabricator_project.project to reorder milestones.

Is sorting by Space ID (instead of Space name) definitely your preferred sort?

This is unintentional, I only meant to hide archived projects on workboards. They're incorrectly behind hidden in all contexts.

Sorry, I'm still not sure I quite understand the specific use cases for this feature that you anticipate.

The benefit of enabling ControlPersist is only very slightly faster SSH connections, right?

Do you legitimately have several distinct "profiles"? What differs between them?

@20after4 It would be helpful to get a sense of what your ideal tree looks like -- would adding the immediate parent project always be sufficient to disambiguate things? Or would it produce 30 different projects named iPhone > Bugs because the full hierarchy is CrazyFlaps > iPhone > Bugs, FlappyFish > iPhone > Bugs, etc? Or do you have a mixture of hierarchy depths?

If the parent is already a parent project of some other project, it has no direct members, so nothing will be copied. --keep-members parent should do what you want, provided you move "Members" first, before "Subproject A" or "Subproject B".

@nochum, can you explain what you're trying to do in more detail?

Quick summary here:

I also think the current per-service and per-device granular locking might be better off as a cluster.locked global configuration which prevents creating or editing anything touching a cluster service, so I may pursue that.

This just sounds a lot like "I ran rm -rf /var/repo/X/ and all the data for rX vanished" to me, which is completely expected and should be predictable.

None of the repository replication code is even written, though. What behavior do you expect today?

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.

Suppose you have a hosted, active repository and do this:

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.

Does changing window to 31 actually fix it for you?

Workboards only. See T4213 for discussion of themes and skinning.

Thanks for verifying the fix!

In the Phacility case, I can also just give these networks a "no one" edit policy, but still need to do the namespace locking.

From IRC, I think it sounded like this wasn't really a bug so much as a confusing UI (expecting to type one thing when the UI wants something different), exacerbated by the lack of "Browse" working. I'm just going to realign this to be "make browse work".

I think this is now resolved for PHP 5.6 at HEAD of master.

I don't believe we've ever supported this.

Never mind, that patch doesn't work.

Yeah, I'd like to avoid that "simple workaround" of 200 lines of spaghetti if I can, since I'd guess this task is going to go through 50 more rounds if I have to implement that.

Alright, thanks. Both you and @ppggff have PHP 5.6, I'll see if I can reproduce with 5.6.

Why do you want to set a global default background? What is the root problem you're currently encountering?

@dpatou Do you have errors in your error log similar to the ones @ppggff describes?

So your client is sending an HTTPS request, but $request->isHTTPS() is false?