Actually, this also means that users can't copy/paste the thing in the web UI, right? They'll need to copy "ssh://secure@secure.phabricator.com/source/phabricator.git" from the web UI, manually edit the URI to have their host alias, then execute the command?

I made the claim that this is the easiest way because my experience is that "have all your users do something" is always harder than "do something yourself", at least in the roles I held at Facebook and here. I'd gladly solder pins on the motherboard if I didn't have to tell users to make a simple configuration change.

Ah. I believe I fixed a simpler version of that case earlier, but not the specific case you describe. D16881 should fix that case.

• D16853 tweaked one issue that I caught.
• T11881 is a followup for restoring code diffs in a small set of scenarios.
• I haven't seen other issues for a while, so I'm going to consider this resolved until they crop up. If you do run into cases where the new algorithm isn't doing a great job, let us know.

• D16877 includes the entire CLDR "windows to the rest of the world" map in things we'll recognize.
  • Neither that map or the Microsoft map have "Russian Time", but maybe that's just what the UI shows for zones like "Russia Time Zone 10", and not what actually appears in the ICS file? Otherwise we're going to have to keep digging.
• D16878 fixes the form customization stuff I mentioned above, mostly by preventing quirky/confusing fields from being customized (at least, for now).
• D16879 fixes a rendering bug with "All Day" events that could shift them forward or backwards by a day.
• D16880 uses the same rendering logic for subheaders (which now appears to be correct) and tooltips (which had a different, older copy of very similar logic).

From T11878, these patterns aren't obvious:

It also occurs to me that if I needed multiple and conditions I could make a rule that did nothing but just matched those conditions,

• Editing the EditEngine default form and removing "Host" means that "Host" no longer prefills. This is the same as T10222. A temporary workaround would be to prevent that field from being defaulted. It should be defaultable in the long run, but is probably low-value to assign a default to, so it's probably better to just lock it for now and make it behave a little more sensibly.

Some other stuff:

epriestley's "Another herald rule" condition does not solve the problem.

No, there's no specific support for LFS mirroring yet.

Configure ArcanistTextLinter, which can detect and automatically correct these errors:

Oh, sorry! I added you to Community so you should now have edit power.

Why doesn't this work?

You can already do this with the "Another Herald Rule" condition.

Feature requests require a root problem description (see Contributing Feature Requests and Describing Root Problems). Feel free to file a new feature request completely describing your root problem. If you do, please read all of the documentation carefully first: it lays out exactly what information we need to move forward on a feature request.

It would be great, if this would not be necessary.

T11864 is another flavor of [ ] Show on commit message template., like T7327, although it wants to hide "Subscribers" instead of show "Projects".

adding them as a Reviewer achieves the same purpose

I'd be thrilled to answer questions about third-party application development or Phabricator's internals, but unfortunately we can't offer that for free -- it's very time consuming and usually only benefits one user. If you're interested in help with modifying Phabricator or developing third-party applications, see Consulting.

I can't reproduce this. Here's what I did:

I'm happy to work with you to answer questions about my local environment and try to narrow down what's different, but we charge for this because it's very time consuming and often only helps one user. See Consulting for details.

We haven't received additional information that allows us to reproduce this issue, so we can't move forward. Feel free to file a new report in the future if you can provide complete reproduction steps.

I can't reproduce this. Here's what I did:

• D16865 should treat "W. Europe Standard Time" as "Europe/Berlin". We'll figure out some better solution for this if it continues being an issue, I'm just still hopeful that we can get almost-correct coverage with a handful of explicit mappings/rules without needing to do anything more complicated.
• D16866 should give the datepicker more reasonable behavior on mobile/tablet devices (the panel should now center on screen when activated).
• D16867 should fix the issue with all-day events sometimes extending too far in the summary text on the day view.
• D16868 improves behaviors around inviting projects to events on the day/month/detail views.
• D16870 makes a query for "Invited: epriestley" mean "events which epriestley is invited to, or any project that epriestley is a member of is invited to". You can find just individual invites with "Invited: exact(epriestley)".

The implementation effort required to support arbitrary VTIMEZONE entries would be fairly huge, since we'd need to reimplement the PHP builtin classes DateTime and DateTimeZone and basically write a full date handling engine. I believe there is no compelling reason for software to ever specify an event in a timezone which is not part of timezonedb (I believe timezonedb is accurate, exhaustive, and fairly ubiquitous; and RFC5545 mentions it, although it does not require it be used), although mapping VTIMEZONE names to timezonedb names may be difficult.

How could we edit T4213 to make it more clear that it applies to all discussion of themes, skinning, and custom CSS, including fonts?

@vills, see T4213 for discussion of custom themes, skinning, etc.

We distribute "Aleo", but this font does not include cyrillic characters or some other extended latin characters (like "ğ" and "Ğ", from Turkish). It does include some extended latin, like the Polish "ł".

You can remove "Test Plan" by disabling the field in differential.fields in Config.

From that trace, it's possible that there's an issue in the vein of T9898, if the repository has an enormous number of branches (tens of thousands?).

What happened before that?

We queried a subset of free instances to gain insight about free instance usage patterns (mostly: are they actually being used?). Specifically, I ran these queries to count repositories and feed stories on a subset of free instances:

Actually I guess this (storage format in commit history) is largely unrelated to that (display format in web UI).

T11114 should fix this for free.