What is the root problem you are looking to solve? See Contributing Feature Requests and Describing Root Problems.

Or more specifically, I don't intend to add this back without spending more time thinking about the problem it solves. There are other possible solutions (including allowing installations to customize a user's sidebar) but in the context of doing a code review, I can't think of any benefit here. It's helpful for us to understand the entire problem you're looking to solve. If knowing a user's current revisions is important in the context of performing another code review, we'd like to know what that information is and why. What information do you get from it, and what decisions do you make differently because of it.

Sure, apologies for the lack of clarity.

I want to see what a user is working on/has recently landed, and the previous (like up to a year+ ago) view with an unbucketed list of the user's revisions sorted by time was helpful (example). In larger installations, seeing where a user has been making diffs is useful for a variety of purposes, not just during code review, mainly to understand what they actually do for their job or where they have been working recently. Or in the other case, when someone messages you via an external chat client and asks you to review their code that they haven't added you on, it was pretty quick to go to that user's Differential page and take a look.

I guess the root issue is that in our installation, the Commits log linked on the user page is an absolute mess, since there are several repos that are automatically committed into at seemingly random times, which causes the page to be totally out of order and a total mess. Here's an example of my commits page screencapped just now, noted that I have never directly contributed to repos 1 or 2. (note timestamps too)

I'll take a look at the commits bug here shortly. Do you expect your install to keep more up to date?

I believe there are plans to update it more than once a year at least

If you just updated after more than a year, you are probably seeing imports from the change in T6878. Once those finish, things will settle down and "commits" will begin reflecting what you expect.

Specifically, we previously did not import commits which were only reachable from a tag or ref. We now do. I would guess that all of those surprising commits are reachable only from tags or refs, and not from branch heads.

For ordering purposes (sorting, feed), we don't back-date commits because this would allow an attacker to hide activity by backdating it to a year ago (you can freely mutate the commit and author dates in Git) and possibly escape notice.

That is, we order things by discovery date (when we learned about the existence of the commit), which is tamper-proof, rather than author date or committer date, which are freely mutable by the client.

See also D16456 for commits from 40,000 A.D and D17136 for commits with no timestamp information at all.

(Commit-date ordering would also mean that forward-dated commits would be stuck to the top forever.)

Interesting, that decision makes sense to me.

I guess the other cause of commits being a mess is shadow repos that exist on our install that are automatically committed to at a later date. Contrived example, every friday at 10pm all of your commits are committed into rRepoShadow automatically. These do show up in the commits window, which makes sense, but still aren't very useful for someone just looking for the most recent activity of the user itself.

In the case of a workflow or automated setup where one diff can cause multiple commits at a later date for whatever reason, the commits view becomes less useful than the diffs view if you just want to see what a user has been up to recently

Yeah we had both "commits" and "revisions", which had a bit of overlap. My main concern was if you were using this information to learn about a person, actual commits should hold more weight over temporal information like revisions.

Fair point, there was a bit of overlap, and the end result of a revision is super important (the commit).

I find the differential view to be super helpful, since any closed one is approximately equivalent to a commit, but with the revision history attached. External to that I secretly love looking at someone's reaction to code review/feedback.

I guess the final solution to this would be allow customization of that menu. Or was there one specific diff that removed that removed that menuitem?

So, what's the word on this?

I don't see a compelling reason to add a link to every Phabricator install for a single user.

We're OK leaving this open to understand impact to other installs or similar needs in customizing user profiles, but to date no other requests have happened.

Awesome, makes total sense to move this towards a customization of user profiles task. Thanks!

Hey, we're also interested in this by way of T12545 (which was merged in above). A couple of our teams have historically assigned their oncall/tech-debt tasks to a mailing list user, and used the priority-sorted view of those tasks to run their oncall shifts. That workflow no longer works with the reverse-chronological sort.

If it's undesirable to switch the sort order back, would it be possible to, e.g., link a query for the tasks for that user sorted by priority? I think something like that would be massively helpful - sounds like this task as a whole isn't on your immediate roadmap.

Sounds reasonable to just improve that.

Possibly also, add a "See All" link to ApplicationSearch

Thanks! That should be perfect.