Context isn't automatically unfolding around inlines, but should.

Oh, and maybe lack of source code intraline diffs, although that's likely not too much work.

I think the major remaining issues are:

One broad problem here is "chain of custody" issues in T182. A "Saved State" can easily accommodate multiple representations, and the plan above imagines using Drydock to build tags/branches out of non-repository representations, so we'd have cases where a given "Saved State" has a way to build it with a "patch list" (from the client) or a "ref pointer" (from Drydock).

OIDC is just OAuth2 in a ghost costume, so the implementation is nearly trivial.

I'm not sure how I'd even test OpenID these days. Offhand, I haven't seen any provider offering OpenID in years.

??? it just works ???

Jupyter as blocks, no diffing or inlines yet:

• Differential shows a "this file is big, so syntax highlighting is disabled by default" warning even when a document engine which does not use syntax highlighting renders the document.

• There's also no "render as native source" option, but there is a "View as Source" option, which doesn't work. Gotcha!

• The options in the "View As..." dropdown are exhaustive, and most do not work, because they aren't based on the changeset being rendered (so we'll give you an option to render a Jupyter notebook as audio, for example). This isn't trivial to fix and it isn't terribly important for this to function as an escape hatch back to old behavior.
• Since we expect most documents to have a relatively small number of options here, a list of clickable options might be better than a <select /> dropdown.

In an effort to "do no harm", I'm planning to add a "Render with Document Engine..." option to the View Options dropdown next. This will let you (for example) view a Jupyter notebook as a raw source diff if you want, if the "fancy" diff is broken or unhelpful for some reason, so you always have an escape hatch back to a lower level representation.

• TwoUp image comments aren't triggering (also in master).
• OneUp image comments need some cell span adjustments.

I've moved the issue in PHI1264 (roughly, "commenting on an unpublished commit should still work normally") here from T13284, since it ended up not really fitting into that scope particularly well.

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).

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/**.

(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:

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):