This fix is not retroactive (and, I think, isn't easy to make retroactive in an obviously safe way) so you'll need to manually repair affected repositories if you want to fix existing commits affected by this bug. This bug doesn't likely doesn't have any far-reaching implications so there's no need to go on a grand adventure to hunt these down, but if you've run into some you can fix them like this:

Add a bin/repository refs --rebuild or similar flag to repair repositories affected by this bug.

If this theory holds up, the "swap a branch" case can be reproduced like this:

Retrying this on the patch:

The problem isn't that it's in rough shape (I'm fine with bringing rough stuff upstream), but that it's something I may eventually want to license as a paid extension. I generally want to stop bringing "free glue for paid systems" upstream (T13229).

How about landing this as a prototype?

The "import a repo" case can be reproduced like this:

If this theory holds up, the "swap a branch" case can be reproduced like this:

If this theory holds up, the "swap a branch" case can be reproduced like this:

The algorithm in PhabricatorRepositoryRefEngine->updateRefs() is approximately:

See PHI1447. In this case, the install reports a sequence of events roughly like this:

This now appears to be fixed in the release version of Chrome. We can remove the workaround in some future change.

Oh, no, that's unrelated:

Looking at this in slightly more detail, I think the immediate issue is just that .gitignore specifies /src/extensions/*, not /src/extensions/**.

I actually tried to use the extensions directory to hide Composer's vendored files and ran into this same issue.

(This has been made to exist, at least roughly; see PHI1448.)

TravisCI sold to Idera and is no longer "cool".

I generally don't plan to upstream any more support for third-party build tools, since I don't think a future where Phabricator is free glue for a bunch of paid systems is desirable. The pathways forward here are either:

get rid of all obsolete / policy-violating stuff so no part of the Facts application is broken;

og:title should probably be the post title.

Looks like Twitter's dialect of og tags is slightly special, but nothing too crazy:

This would also be great for Phame, so that sharing a link to a Phame post results in a title card when shared on Twitter.

I believe charts in the UI now make physical sense. They aren't very fancy/polished yet, but everything I see on this install looks cohesive (no more overlapping negative areas, weird gaps, general nonsense, etc):

The "compose(...)" function won't select input values correctly if the first function in the chain isn't a data function. For example, if we compose:

D20814 combines nearby points so we don't have tons of overlapping tiny circles. For now, the grouping is just based on X-axis distance:

In stacked area charts, when we stack areas, we accumulate some error by stacking integer points on top of interpolated points.

if prototypes are disabled, some stuff is broken, particularly "View Chart".

At the lowest levels:

This needs a lot more work, but here's very roughly where I'm trying to go with this:

D20808 fixes the two original cases (Harbormaster and Legalpad). There are probably more fields or actions which could be configured to be sometimes-unavailable, but these are probably the major ones.

For LDAP, brew install openldap + --with-ldap=/usr/local/opt/openldap/.

Here's the fate of the various issues discussed here:

This should be reworked some day (perhaps partly here) into some more cohesive API, perhaps newLink().

One other thing is that PhabricatorApplicationPolicyChangeTransaction->renderApplicationPolicy() has unconventional behaviors which are not very helpful and not consistent with normal CAN_EDIT / CAN_VIEW transactions. This is somewhat perplexing because ModularTransactions has renderPolicy() already, which has better behavior. I think it didn't exist yet when Applications modularized in D17757, and when it was introduced in D19829 I just overlooked the opportunity to update it.

In Applications → (Pick Something), if an application policy is set to "Custom Policy", the policy is not linked.

I upstreamed this to Chrome here: https://bugs.chromium.org/p/chromium/issues/detail?id=1003002