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)

In T12804#226344, @epriestley wrote:

What do you use file content search from the web UI for? (That is, in what situations is web UI search better than git grep?)

I execute content searches very frequently (hundreds per day?) but about 99.9% of them are git grep and maybe ~0.1% are web UI.

What I would really love to see is global filename search. Currently you can search for a filename within one repository but you have to know which repo to look in first.

We have thousands of repositories and it's hard to differentiate in a list which repository I need.

I would also say I use git grep locally probably 95% of the time, and web maybe 5%. It's not part of my usual routine.

I don't want to assume everyone is a knowledgable engineer who is sitting at a desktop with a cli and the code checked out. Diffusion to me is a web front end that is much more enjoyable, sometimes quicker, sometimes slower to browse and search for things in codebase that maybe aren't "I'm, coding right now" related?

In T12804#226344, @epriestley wrote:

What do you use file content search from the web UI for? (That is, in what situations is web UI search better than git grep?)

I execute content searches very frequently (hundreds per day?) but about 99.9% of them are git grep and maybe ~0.1% are web UI.

In T12804#226305, @epriestley wrote:

In T12804#226290, @sascha-egerer wrote:

T8442 would help a lot for those "I have to many repositories"

Today, you could save searches in different Spaces. For example, here I've done this:

• Search for "Spaces: Phacility".
• Save the search as "Phacility Repositories".

Do you use this strategy today? How would T8442 improve on this? If you don't do this already, but dividing repositories by Space is useful, why don't you currently do it? Put another way, what problem exists with search today that T8442 solves but search changes could not solve?

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

I like GH search where I can see content before and after the term searched for. This has been helpful for migrations where I'm searching for something generic like addButton that is on multiple classes.

What do you use file content search from the web UI for? (That is, in what situations is web UI search better than git grep?)

I'd be happy if you just added Grep File Contents search at the base repository view. It is kinda annoying that I have to click into a sub-folder to grep (sometimes I don't remember which folder it is in).

In T12804#226303, @epriestley wrote:

Maybe I'm misunderstanding what you mean by "omnibox"? How do you use the search input to search for anything other than file content?

💯

Thanks - I thought it was already filed but couldn't seem to find it.

(I think that's also filed in T10767.)

I'd love folder shortcuts (for directories that only contain a single directory). Clicking through a few levels in various Java projects would be slightly more pleasant.