Alrighty, I'll take a look at it. 💯

Mock above rebased on master and apparently working:

Let me see if I can dig up my hack-branch above and hand you a skeleton for it.

Yeah, this is relatively simple if it's on a separate page, and can be built in 20 minutes if there's no sorting or "Hide Done".

To step back slightly, one problem we know users have, which is motivating at least some of this request, is "90 spelling corrections". T8909 has a specific example of that, and T8909#224085 alludes to a flavor of this ("90 style corrections") elsewhere. I don't think this is a problem that users "should" have, but I suspect it's responsible for between, like, 50% and 85% of this request (maybe I'm way off, but I'd bet dollars to donuts that it's more than 2%), since it's the case where managing inlines is most overwhelming. And human reviewers are somehow often unable to resist making 90 inlines about style/spelling corrections, even when everyone is worse off for it.

I do think this is something I would have used in the past when faced with ensuring I've addressed all feedback for multiple designers. So in some part, I feel I understand the core problem users are looking for. I don't think we can fix abuses like the 90 comments on spelling errors, so that's not something I feel I need to consider in this design. I just want to make sure I haven't missed anything as an author, or that as a reviewer, all my comments have been satisfactorily addressed. There could be something to explore in that second directive, but we haven't seen a lot of issues in that area, so I'm not really concerned if this is the best solution for that. Wanting a view of only inline comments and the ability to reply isn't something I want, as I feel Differential already does that.

I suspect that isn't what very many users want (I'd guess like ~10%, not ~98%?) -- or, at least, doesn't really solve whatever problems they're running into. For example, I think the "90 spelling corrections" diff in T8909 wouldn't benefit much from this (it doesn't help you go through 90 spelling corrections or 90 lint style fixes), and it's the opposite of the request in T5654, which sounds very similar to this to me. But maybe T5654 is really just "our users like GitHub, so make it look similar to GitHub so it's more familiar", I'm not really sure.

Alrighty, took at pass at this I think isn't too much work, and is probably 98% of what people want. Specifically tried to look at the following scenarios:

My solution to this problem was to compile version 3.4.2 of mercurial and install with a different PREFIX, and only use it for pushing to phabricator. That way I can use the latest version of mercurial for everything else.

@jcox ???

(We also likely have a similar problem for hg that D18105 won't fix, and can't use the same strategy there since hg grep has no -f flag or equivalent.)

Note that D18104 is not retroactive, so existing feed stories aren't expected to change after upgrading. New feed stories published after picking up the fix should show "alice committed <commit>" as the title again, though.

It looks like the current behavior rose out of D16268 / T11309, although it was something of a side effect of those changes.

In T12804#226525, @epriestley wrote:

In T12804#226522, @bjshively wrote:

The pagination view for very large source trees/folders (in our case located at ourdomain.com/diffusion/name/browse/master/averylargefolder/) is confusing. Specifically, the pagination buttons are placed below related Open Revisions. This can often be confusing or misleading, as it is not immediately obvious that you're not seeing the full set of files.

It might be clearer if these buttons were immediately below the content being paginated (i.e. sandwiched between the averylargefolder list view and the Open Revisions.)

The pagination view for very large source trees/folders (in our case located at ourdomain.com/diffusion/name/browse/master/averylargefolder/) is confusing. Specifically, the pagination buttons are placed below related Open Revisions. This can often be confusing or misleading, as it is not immediately obvious that you're not seeing the full set of files.

Existing sources of permanent failure are worth at least a cursory review before we ship this since they're pretty easy to grep for, but I don't anticipate any issues.

See also T7339 and T5554. But the approach we are generally taking there is "wherever possible, use a method where locale configuration is not relevant", which is consistent with using -f -.

This works properly on my local machine (OSX) so it's some kind of Ubuntu UTF8 CLI thing.

This is now available in HEAD. See M1476 for a mock. The actual feature doesn't quite look like that yet since the buttons use generic styles, but should soon (see also T12688).

On GitHub, all remote URIs are read/write, but in Phabricator some may be read-only.

Some purely technical stuff:

Herald rule:

Hello, we used this function (add project to a commit by Herald rule) as well happily for about two years (last update of phabricator was 03/16/2016). The current phabricator update (06/06/2017) now lead to messages in the activity feed in the form of "Herald added a project to rXXXXX: <message>: <project>" and the commit itself (or better the message) does not appear anymore. When we disable the Herald rule the commit-messages appear in the feed again as before and expected.

There are debian and ubuntu packages for arcanist:

• https://packages.ubuntu.com/zesty/arcanist
• https://packages.debian.org/stretch/arcanist

although popcon data (66) suggests that the debian one is not in wide use.

Please read and follow Contributing Bug Reports if you think you've found a bug in Phabricator. Specifically all bug reports require steps that reproduce for the upstream developers. If you have general questions about Phabricator administration, please use Conpherence or Ponder. Thanks!

yes

Does this work without using arc and just normal git commit?

I feel that in a multi-repo environment, project PTags and Description are very important, and in a very-small-number of repos it will probably be empty, so I'd vote "Show them above the fold".

.jpeg.png~

The objectives UI wasn't solving any specific problem or really motivated by any particular request, I largely just wanted to try it out and see if it made it a little easier to navigate diffs in general. I think at least some of the feedback in the vein of T8250 is roughly "it's hard to see the big picture when changes have a lot of comments", and it seemed worth trying to see if we could make the big picture a little more clear without splitting the UI apart completely. Some (most?) IDEs have similar features, where either things like functions/classes, or lint warnings, or compile errors, are marked in the scrollbar or a small view of the file is shown:

Is there a pre-cursor to D17955 I should read up on? Or was T8250 the main impetus?

I could go either way. At least 0/2 feels bad since it then gives the impression we think you should be marking stuff done. Let's just kill the 0/2 case. Only show / if 1 is marked done and see how that feels. I can clean up the UI before cut too.

If you haven't checked anything and are the author (i.e., today, button is visible and says "0 / 2"), clicking it takes you to the first inline. That's at least a plausibly useful behavior?

I probably should spend more time thinking about this UI, or maybe I should have taken more notes when I designed it.

"3 Unsubmitted" is the three synthetic lint about "TODO"s in the code (see T12806).

On D18102 I see other people's unsaved comments, I think. I also expect 0/2 to only be visible to the whoever can mark stuff done. Otherwise maybe just 2 or nothing?

I think the Twitter server has some uncommon load issues, partly because a git at twitter has some unusual load issues (I know Twitter had to patch git locally at some point to make it work better). You should probably reach out to the internal Code Review team and complain again.

Noted, OK. We'll proceed by adding our own local ./bin/storage endpoint for it.

Yes. (That is, I'm adverse to upstreaming this.)

Would you be adverse to accepting a patch that does this?

We haven't received the information we need to move forward, so I'm going to close this. Feel free to follow up here or open a new task if you're able to provide detailed reproduction instructions we can use to reproduce the issue locally.

In T12804#226416, @chad wrote:

I don't believe moving buttons and changing layout will affect page load speed. If you have real performance issues, we should address those in another task.

Though we could remove branches/tags on the initial home page of the repository, I'm only seeing about 500ms a load.

"Wait for T12681, then pay us a lot of money." See also T12778.

I don't believe moving buttons and changing layout will affect page load speed. If you have real performance issues, we should address those in another task.

I'd like to see little forward and back arrows at the top of the page when viewing actual commit objects. This use case might be unusual, but I've needed to find "the last commit before DXXX" and "the first commit after DYYY" a few times. GitHub doesn't appear to offer this either, but it feels a little easier than just providing links to the parent commit.

I think the majority of issues I (and many others at Twitter) run into is due to performance / slow page loads. If there is anything in the UI that could be minimized / simplified to speed up page loads, that would be really helpful. However, I imagine that performance is mainly a back-end issue (and probably our instance's fault in some ways).

I think branches could be more accessible so I don't have to scroll to the bottom of the page, especially if my file tree is large.

I think "search across multiple repos because we have 2,000 extensions" or whatever is a great use case, that just didn't seem to be the motivation of any of the requests above -- I think it wouldn't make sense to put cross-repo search on the main page of a particular repo, or particularly on subdirectory browse views.

In T12804#226348, @epriestley wrote:

You can use, for example, -C3 with git grep to show 3 lines of Context around each match.

About 95% of the time when I'm searching for content it's because I want to edit a subset of the callsites. I do this with git grep some_function | maybe_more_grep | give, which opens all matches in my editor. This would take me about 100 years from the web UI for a nontrivial number of results. Do you have some other use case for searching for content?

My rough plan is to get rid of all the curtain stuff and move to button bars so the content can be full width. Owners stuff could get a new UI under the file content.

I just mean the curtain, yeah (It can be a largish chunk of the screen on a laptop)

It's limited if your company doesn't provide you with a 31" Dell monitor.

Maybe this is a better screenshot:

Slightly less important is that the width in the Browse File page is limited

When grepping in a repository, the results should (optionally) be ordered by their blame date.

u w0t m8

This is now deployed here, to secure.

In T12804#226366, @epriestley wrote:

When I view a repository, it would be incredibly helpful if the files I most recently touched were at the top of the UI.

When I view a repository, it would be incredibly helpful if the files I most recently touched were at the top of the UI.

(Some of this discussion is pertinent to T9287: Working with many repositories)