Tentatively, I'm thinking about doing this (some discussion in T4788, too):

I think the commit stuff is working properly already -- the code is a little tangled, but we try to merge revisions into that section if we can, and only render it separately if we need to. That is, we attempt to render:

Yeah I think the need for corporate users to hide things from their enemies is probably outside of our control. Just try to find lots of bugs with it.

I'm a corporate user and I love hiding things :(

Oops -- I assumed that package was someone testing things since every other object that has ever been hidden has been and ran bin/policy unlock without examining it, but it's actually a legitimate package. I think I put it back the way it was.

You're currently the only user we're aware of who experiences this -- have you tried changing your IDE so it, e.g., only polls git while in the foreground?

See also T4788 for some other followup work.

Thanks for being so fast fixing this.

Because of the intermediary join to the edge table I wasn't actually able to get it working without HAVING either, but D16340 should fix the underlying issue here.

Thank you for your attention to this issue!

I believe the best way to construct these queries is like this:

I'm planning to make these changes:

A subproblem here is perhaps that Owners should have a "Can Create Packages" policy.

As a thought, it might be nice if Administrators could pin other items to the menu bar, not just Repositories and Projects. For us, it'd be nice to pin a "Developer Enchiridion" wiki page to the menu bar.

Currently debating if that menu should be available globally (on every page) from a menu item in the header if you're not on home. I don't know how much I'd use it. I sort of explored having it be a single "Favorites" that you could have everywhere and modify anywhere. But it might make more sense to have a simple home sidebar and a separate "favorites" to replace the quick create menu.

(That was my attempt at a different, less eye staring into your soul, logo).

That isn't the logo we're planning to use. We haven't settled on a final logo (we had external designers come up with new ideas). Still testing stuff locally.

(Though I really like the sidebar menu with projects / repositories / create new)

FYI the logo in the design / mock doesn't really look like an eye - it makes me think of a gear not an eye with a gear.

Related to T11344

There isn't a wordmark in the redesign, it will just be a text hyperlink (which you can customize).

For the very little it is worth, my coworkers consistently refer to our instance as Phab, matching the subdomain we gave it, and currently have a mark like

No biggie, although the UI effect is obviously crucial for my org

Whoops, yeah the strikethrough isn't for some reason. Sorry I thought you meant an issue with the graph itself.

For what its worth, the biggest violators at my company tend to be company executives who (sometimes) rightfully wish to skirt our process. But, when they see how trivial it is to skirt our process, they're tempted to do it more often. And then they do it more often.

See T7924 for current Calendar roadmap items.

I'm not exactly sure what this is asking for -- it sounds like you just want a more convenient way to post a comment asking revision authors to "Please re-run the optional tests."?

So CalDAV support (for iCloud and others) is not planned? Google Calendar API is propritary while CalDAV is a standard. There is a really good php implementation of client/server and card parsers: https://github.com/fruux/sabre-dav
@devurandom yes that is true, and it is really simple using save/dav.

I think you're free to fiddle -- there are some more adjustments and things, but nothing too significant. I think the only other really CSS-ish thing is that if you search for events in a specific range (July 5-7) on a calendar view, I'd like to make it clear which days your query covers.

land what you got and I can start fiddling? or did you have more?

This is working as intended.

Project menu?

After D16333 there's still a tiny amount of unique spelling correction code in Arcanist, but it's just calling into libphutil and part of code duplication which would be better resolved elsewhere (like T7487).

For completeness, I'll also drop a mention of T5024 here, although I'm not yet sure how the two might tie together.

We do not currently support RTL languages. You can follow T5267 for progress on internationalizing Phabricator, but we currently expect to support LTR latin languages first and it may be some time before we support RTL languages.

You are in the wrong place -- it looks like you mean to be on Uber's internal install of Phabricator, but this is the public upstream install of Phabricator.