We haven't seen more interest in this since 2012 and this task no longer meets modern criteria for feature requests (see Contributing Feature Requests).

Kicking this out of scope for now.

I think D17298 is probably a good change for Favorites either way (so we don't have a "pin" UI there that doesn't do anything) since it's pretty simple.

Pinning on Favorites has no effect.

You want to use top-most displayable even if the user has two personal dashboards and has explicitly clicked the pin icon on the second one to make it their default item?

You can change the rules for picking a default item in PhabricatorProfileMenuEngine->loadItems() if you want to use different rules.

There isn't a way to un-set a default, or pick a different global default as a default, although you can effectively do either by creating a copy of whatever global item you want to be default and pinning it, except "magic home", which you can't copy. So there are a couple of messy edge cases there but they don't feel too important to me.

If Admin "sets default" on Global, and users have not set a default, the page follow admin default. (I had to set my dashboard as default, as seems to be no way of un-setting a default).

• For HTTP, this is broadly expected in some sense until T4369 is resolved.
• For SSH, this is not expected but the linked file is 1.75GB. Did you encounter this in a more realistic scenario and the size of that file is just for demonstration purposes, or are you trying to store ~1GB binary assets in a Git repository? Git is generally not well suited to serve as a binary asset store. GitLFS (T7789) or possible future changes like T11367 are likely better fits for this use case.

Completely fine to make the engine aware of the viewer running the query, I think we just didn't have use cases for that when this stuff was written.

In 99% of cases, the right thing to do when you see an error in the daemon logs is:

This report is missing version information. See Contributing Bug Reports and Providing Version Information for help. To move forward:

We can only accept bug reports against current versions of Phabricator, as detailed in Contributing Bug Reports. Feel free to file a new report against a modern version, if this issue still reproduces at HEAD of master or stable.

I think D17294 + guidance is maybe good enough?

I'm going to close this as tentatively resolved since it's fairly old and things have changed a fair bit since it was filed. I believe we may now handle this use case reasonably well. If you still have use cases for this that aren't addressed at HEAD, feel free to file a new issue describing what problems you currently face after upgrading (following Contributing Feature Requests).

Why do we need to allow it to be hidden?

It looks like it works, it's just a little confusing since "Home" doesn't show up. I'll fix that:

Also, we might be torpedoing open-source installs which don't have a dashboard right now since the magic "Home" doesn't show up if you're logged out. I'll look at that.

I think that's a whole pile of work, I was just thinking that administrators could disable the global item.

Leave the default fake 'Home' as is (corporate install, your stuff)

I also, generally, can't come up with any uses for links that or other items which are only visible after you log in, outside of dashboards.

I'd like to wait until we have a good answer on how we'd use this feature before we pursue it. I worry that it adds a significant amount of complexity and may really have zero use cases. In the best case, it is useful to only a tiny number of open source installs.

Oh, or is that non-hypothetical?

How would you like the two dashboards to differ on this install?

Oh, maybe I misunderstood then. How would you like to make the logged-out vs logged-in menus different on this install, or how do you think other open source installs would benefit from this? (This only impacts open-source installs, right?)

I'm not really sold on the use case -- which is just letting open source installs have a logged-in dashboard tailored to the user, right?

Please follow the rules in Contributing Feature Requests when submitting feature requests.

• After D17282, we do branch=phabricator/diff/689, commit=HEAD when building revisions.
• After D17282, we do branch=<one arbitrary containing branch>, commit=<commit hash> when building commits.
• The "GitHub Settings" workaround above resolved the "tags disabled" issue, as suggested.

Yeah, run bin/audit synchronize --all (or rXYZ for just one repository) after doing manual cleanup with bin/audit delete. This is noted in the documentation at HEAD as of ~yesterday, although it may not have regenerated in production yet.

I think I've pushed this approximately as far as I plan to in this iteration. Everything mentioned in the description has been tackled, and audits on this install are now in a relatively sane state.

(arc list will also grow some kind of --reviewer=me --status=open mode in T7715, but I suspect that no one would really care if arc patch just did that by default.)

D17283 allows you to double-click the D1234 crumb to select it, since it's no longer a link. I don't know if double-clicks are too complicated or not.

The selection junk is caused by float: left which apparently fixed some kind of IE thing in 2014 (T5902) so that may be involved to fix.

Also a lot of users do not notice this text is in the URL since on Safari the browser hides everything except the domain until you click on it.

One general improvement we could make is to have arc patch without arguments offer you open, non-authored revisions in the same repository, using the new numerical menu selector from T10895. That might moot this, and I can't immediately imagine any other default behaviors for arc patch with no arguments (other than showing you how to provide arguments, as it currently does, but we could retain this text in an abbreviated form).

I'm also confused about this:

arc list will eventually be more flexible (T7715) but today it's only your stuff.

Er, oh, other reviews. Then maybe this feedback should be on T12026, rather than here.

Oh, then arc list?

@jcarrillo7: there is no command line way to get back a list of reviews (with their identifiers) that are active for the current repo.

We queried a subset of instances to gain insight about how frequently repository data is hosted on GitLab, so we're better prepared to respond to any indirect fallout from a recent operational incident on their side:

Broadly, I'm supportive.

All changes in Phabricator need to be driven by strong, real-world use-cases.