Can you show me the output of these commands?

Actually, I'm slightly wrong about dropdowns-in-dropdowns being the issue, looks like some kind of rendering order problem instead.

Dropdowns need a bit of CSS tweaking but they feel OK to me.

e.g., pretty sure we can do slightly better than this without resolving any big philosophical questions:

We can/should also make hovercards richer -- I think that's mostly "free" in terms of product/design tension, especially for cards like mocks which have received very little attention.

Yeah, I'm leaning toward starting there too.

Oh, I wouldn't plan to make them meaningfully taller vertically -- I'm primarily imagining a very small adjustment ala "Reviewers" in Differential, e.g.:

Yeah, I think that's totally reasonable. I want to fix up the UI for showing subtasks and revisions and stuff as part of T4788, so I'd expect to do this:

I'd probably turn this into two sections (I guess?) if we had a dropdown/disclosure element:

Some ideas here:

I'd like to have a clearer sense of how we're planning to resolve T10034 before moving forward here, even if we don't actually build any of it yet. Briefly, I think some of the problems here are:

Run your-package-manager install php-xml or php5-xml or php7-xml or whatever it's called on your system.

I followed up on this in #sandstorm on Freenode but this isn't officially sanctioned as far as anyone there knew. They're not particularly happy about this either, but obviously there's little anyone can do about users going vigilante with evangelism.

Oh, you've just been spamming tons and tons and tons of projects with the same message:

I noticed you posted the exact same message that you posted here to Drupal, with the same spelling error of "Oasis":

Custom domains probably need a way to link to an alternate root (e.g., the main company site).

The major custom domain issue is that there's no way to specify a protocol (HTTP vs HTTPS) or port (although this is less important). In particular, http://blog.phacility.com/ works and is the default live URI for that blog, but we would prefer https://blog.phacility.com/ to be the default URI and for http to redirect to https.

This is sort of exceptionally stupid and probably fairly broken until T10769 is further along, but we have a cluster read-only mode now (used when the master database is lost in a cluster configuration). Rather than using it as a disaster recovery / availability mechanism, you could force users into read-only mode explicitly, by doing something like this:

After D16145, Harbormaster should immediately release resources which no remaining (running or queued) build step takes as an input.

There are two completely different flows. At HEAD, the flow is entirely different and uses none of the same code.

This would work now, except that there's no way to change "Edit Policy" from the initial form page.

Yes, this was implemented in T10694.

We discussed this briefly out-of-band, but the draft part of this is probably only sensible as "soft" prioritization:

• Does that description sound approximately like what you're hitting?
• Are both smarter arc land and arc cascade interesting, or are you only running into pain in one of the cases?
• Do you anticipate cases where git reflog and local notes could fail as sources (lots of pushing/pulling to different working copies, I guess)?
• Anyone know offhand how to git rebase -i master; delete the first few lines; save and exit; non-interactively?

I think the immediate issue here tends to manifest as arc land requiring users to manually rebase before it will work.

Here are the interactions I can come up with which we'll potentially get wrong by implementing this naively:

From a technical point of view I think the ideal solution to this is to make the commit message format unambiguously parseable, but I'm not immediately sure how to do that without making other things worse. It's valuable for messages to be human-readable and human-editable, and I think we'd be worse overall if we tried to escape or encode messages in Git itself (or represent them as XML or whatever).

What's the behavior you'd expect or prefer when a user writes this commit message?

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

My understanding is that the root issue here is that you're adding reviewers via Herald/Owners (per T10939) so the "no reviewers" warning is inaccurate or misleading in many cases because owners will be added automatically after the revision is created.

Configure pygments.dropdown-choices.

This is expected. You do not need edit permission to comment on a task or take other actions available in the action dropdown.

This spawned a healthy set of followups, but I believe the core work described here is now resolved and accounted for and all future work is covered in narrower followup tasks.

Appears resolved and accounted for.

I believe this is resolved and accounted for, let us know if anyone runs into issues.

This appears to be resolved and accounted for. There's one followup in T11120 (8bit vs base64 mail encoding) which also might be fixed now. If anyone runs into issues, let us know.

I believe this is now resolved and accounted for. See the remarkup documentation for some details.

I believe this is resolved and accounted for, let us know if anyone is hitting issues.

I believe this is now fixed and all the business stuff is wrapped up on our side. If anyone runs into issues, feel free to file a followup describing what you're hitting.

Sorry, my screenshot was garbage since all the text to the right was INCREDIBLY CONFIDENTIAL SECRETS.

FWIW, examining every ref like that is a complete no-go for our situation

OK, so I just manually removed the branch from info/refs and packed-refs and I think that maybe that worked?

I think D16136 will "fix" the problem and I can't come up with any problems it creates, although it would be nice to figure out where the mystery ref is coming from.

okay so basically ghosts?

In T9028#180932, @joshuaspence wrote:

Ah interesting. From our GitLab host, I see that git branch --all shows a whole bunch of local branches and only a single branch of the form remotes/origin/url_shortener.

Ah interesting. From our GitLab host, I see that git branch --all shows a whole bunch of local branches and only a single branch of the form remotes/origin/url_shortener.

I think checking if git ls-remote origin in the working copy lists a refs/remotes/origin/XYZ ref in the authoritative remote is the easiest way to check, although I'm not 100% sure that refs/remotes/ isn't magic with respect to ls-remote.

I wonder if the actual authoritative repository has a refs/remotes/origin/XYZ ref which we're mirroring?

We fetch bare working copies with git fetch origin +refs/*:refs/* --prune.

In T9028#180926, @epriestley wrote:

Hrrm -- is the repository a non-bare working copy (e.g., has files and folders in it instead of just config/, hooks/, info/, etc)?

Hrrm -- is the repository a non-bare working copy (e.g., has files and folders in it instead of just config/, hooks/, info/, etc)?

OK, running ./bin/repository discover --verbose rX gives me a bunch of output including this:

We have Diffusion configured to track only the master branch, but now Diffusion is importing commits from all branches, it seems.

Updated our Phabricator install just now. One issue I discovered is that we are having a bunch of audits triggered for commits that are newly discovered. We have Diffusion configured to track only the master branch, but now Diffusion is importing commits from all branches, it seems.

It basically runs git log --all, then checks every commit in the database against that list and marks the missing ones as unreachable.

I've pushed this here, and enabled dangerous changes on rGITTEST if anyone wants to try anything.

I think this is resolved, but see T9028 for related followups.

I'm vaguely suspicious that I may have missed some weird stuff here since this pipeline is complicated, but I'm going to land this stuff now and just plan to hold the release a bit if it feels shaky tomorrow.

Can anyone interested in this explain the use case for making it per-Herald or per-user instead of global? Are half your users bitterly opposed to inline diffs, even after we fixed the Differential ones to not be terrible (T10694)?

I'm going to merge this into T9028. Specifically, daemons should be able to permanently fail operations on unreachable commits after D16131. That task discusses deleted/unreachable commits more broadly.

We can't reproduce this, so we can't move forward. Feel free to open a new issue if you are able to provide reproduction steps.

There don't appear to be any major outstanding issues here.