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.

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?

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?

I'm trying to use phabricator in agencies for years now but it's to mixed. You can't say "Now i want to work on project x of customer x". You'll always get everything or you have to create a query in every application for every project / customer. But that is not really something to discuss here but in T8442.
I mean it would be very helpfull to filter everything on space level but keep that consisten accross applications. So i do only see relavant repositories for my current space.

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.

Oh, I'm right there with you. I think this usually happens if I'm not on my desktop/laptop (so the source isn't immediately available) and I'm searching for something. I also switch between Windows/Linux for fun things/work and haven't bothered checking out the source on Windows.

This is a tiny convenience thing and not a big deal at all.

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?

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.

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

This is definitely a problem for Wikimedia's install.

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.

Even more awesome would be full text search over all source code, however, that is a large project on it's own and I suspect that it's not something upstream will pursue any time soon.

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.

I find myself quite often having to show code to other people on computers where git isn't available and/or downloading/cloning repos is not an option, forcing me to use the web UI to show the code. When git's there, I usually use git grep, but the web UI for file content search is a must for me.

The global filename search that @20after4 suggested would also be nice.

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

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

There should be an option to sort lines in a file alphabetically, and I should be able to view every file in a repository ordered by filesize.

When viewing a file, there should be a list of all files with that filename in other repositories.

The whole repository should be viewable as a tree on one page.

I should be able to edit files from the web (T6008).

There should be a default view of repositories I've committed to.

There should be a default view of repositories where my username appears in the content of files in the repository.

There should be a button that lets me take a commit from one repository and make it in a different repository.

Every file and tree should show its content hash prominently (about equal in importance to the name).

It would be nice to be able to search for file content matching a pattern in a subset of files matching a pattern and group results by blame author, on mobile.

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 viewing a file, there should be a list of all files with that filename in other repositories.

The whole repository should be viewable as a tree on one page.

I should be able to edit files from the web (T6008).

Meh

There should be a default view of repositories I've committed to.

Sorted by my most recent commits?

It would be nice to be able to search for file content matching a pattern in a subset of files matching a pattern and group results by blame author, on mobile.

Hahah this one seems a bit ambitious?

u w0t m8

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

On a more serious note, the searchbox (T7701) is probably most important for me (Rarely for myself, but less-technical users also "like"/"need" to search things (Project/Product Managers looking for instances of some words / design people looking for references to images in HTML are the only cases I can remember right now).

Slightly less important is that the width in the Browse File page is limited, which makes browsing files with long lines annoying. I'm thinking maybe a button on the display pane?

Oh, also in that screen, when visiting a file with $123 at the end, the page jumps to the right location twice, which is annoying if I actually want to see/copy the name of the class where a method is defined.

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

Am I looking at the wrong page here? Or misunderstanding what you mean? Or do you just mean that "some of the space is taken up by the curtain on the right hand side"?

Maybe this is a better screenshot:

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

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

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.

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?

When you've got code spread out across a bunch of repositories, and don't necessarily even have them cloned locally, it's very inconvenient to locate where a given callsite might be located. For a monorepo, this isn't a problem and git grep would be fine. It's not fine, however, when working with Wikimedia's massively subdivided ecosystem. There are something like 2000 repos, many extensions aren't even submodules. I think it would take me nearly an hour to clone everything and run the search on my copy.

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.

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.

Also, when browsing some branch, there is no fast way for switching to another branch, so I have to use breadcrumb navigation to view repository "homepage" and once again scroll to the bottom of the page...sometimes it's really frustrating.

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'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 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.

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.

Fair enough. How fast do you see directories in repos load on your instance? I'm seeing 2-3ish seconds on those page loads.

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

This applies to me. Having a more relevant default view for diffusion would help me find what I'm looking for faster. Generally I only care about repositories I've recently contributed to. I could see something like default sorting by repos I've taken an action in / committed in would be great if it didn't degrade performance of /diffusion/ too badly.

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.

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

Have you tried assigning Project Tags to repos and filter on that?

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.)

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.)

Update past D17754 (April 21).

In T12804#226525, @epriestley wrote:

Great, thanks. Guess @jcox is slacking on our updates. :)

@jcox ???

I just came across this today, though I can't recall a time in recent history of it coming up previously. I was looking at a commit in history and wanted to browse through history at that point - if there was a way to jump to the commit history at the point from a commit, would've helped. In this scenario I knew a commit was made shortly after the one I was tracing and trying to locate - that doesn't happen often though.

Supporting Mercurial revset searching would be bomb~

The button. That says Browse. 💃

Hmm the history view on this install is significantly different than the one on mine~

But in my situation I was inspecting a commit and wanted to jump to the history view where it existed, so being here:
rPa36b1e8f64abf187f0007600c369fc95c8d68d2b

And wanting to jump to a view of what's currently listed here (and maybe highlighted revision)
https://secure.phabricator.com/source/phabricator/history/master/?offset=500

There's a link to parent commit but nothing to look at the timeline/history relative to that commit.

Oh jump to the history via pagination and scroll to it? I don't know if that's technically possible. It's interesting though.

Maybe this was the workflow?

• Go to a commit page, like /rXYZ123 • Example
• You want to see "commits in history before this commit", like you'd get by running git log <commit> • Example
• T3216 is vaguely related: the first page does not have branch context but the second one does.

I resorted to hg log -r "descendants('XYZ123')"

good stuff, thanks!

also, T8407 maybe fits here? I think it's mostly a UI issue now.

I'd like the commit graph to come back in some form -- looks like it was removed in rPc5bb69fd7d79. For the reasons @epriestley outlined here: rPf2fcafb40dde#38208, this view is really useful for visualising the relationship between Git branches and sanity-checking recent merge commits. These are tasks that would otherwise require something like gitk.

Our workflow relies heavily on merges. Let's say we have three Git branches, v1.1, v1.2 and v2.0, representing two maintenance releases as well as the latest-and-greatest. Any bug fixes for v1.1 need to be committed to that branch, merged onwards to v1.2 and then merged from v1.2 to v2.0.

Personally I'm reasonably happy to go back to using the command line and/or gitk for visualising the history, but that's not true for everyone. In the extreme, we have remote Windows devs who refuse to learn Git, gitk, the command line or anything associated with it. I can't send these Windows devs a CLI snippet to bring up a gitk window to demonstrate their bad merge, but I can point them to a Diffusion page that they can view using an Internet Web Browser that shows the same thing.

I think we have it documented somewhere that "we have developers who refuse to learn git" is considered a bad reason to ask for a feature, and you should maybe consider solving this issue with some workflow changes.
Note also that in your link, epriestley says

In projects which do not linearize history with arc land + squash merges, I believe this feature is virtually useless because many commits are merges and visualizing the repository isn't very informative (the history has so many parent/child relationships that none of them convey much of anything).

which can translate to "We don't understand exactly what you're trying to see - what's the root issue?"
From your description, it sounds like a listing of "is commit in branch" for a given commit and all/some branches would be more useful for you.

Heaving said that, I did like that commit graph (But I can't come up with an actual use-case where I really needed it).

In T12804#227102, @avivey wrote:

I think we have it documented somewhere that "we have developers who refuse to learn git" is considered a bad reason to ask for a feature, and you should maybe consider solving this issue with some workflow changes.
Note also that in your link, epriestley says

In projects which do not linearize history with arc land + squash merges, I believe this feature is virtually useless because many commits are merges and visualizing the repository isn't very informative (the history has so many parent/child relationships that none of them convey much of anything).

which can translate to "We don't understand exactly what you're trying to see - what's the root issue?"
From your description, it sounds like a listing of "is commit in branch" for a given commit and all/some branches would be more useful for you.

Equally valuable as "what branches contain that commit" is "what commits are in the branches we care about". For us, the answer to this is the commit graph -- it's a succinct, easy to understand representation of our branches and their relationships.

I get that if you only have one primary branch, there's not much value in the commit graph. Similarly, if you're not linearising history, your commit graph will be so messy as to be meaningless. But if you do have the requirement to actively maintain several releases of some B2B software package and have a well defined branching strategy for your team to make this happen, then the commit graph is meaningful and unexpected merges will stick out.

For clarity, we're currently maintaining three active releases, and our commit graph looks something like this:

v2.0
 o
 o
 o
 |\
 | \
 |  \_v1.2
 o      |
 |      o
 o      |\
 |      o \
 |      |  \_v1.1
 |      |      o
 o      |      |
 o      |      |
 |\     |      o
 | \    o      |
 |  \   |      o
 |   \__o      |

Apologies for being glib about our Windows friends. But I really do think it's valuable to be able to send a Diffusion URL to a remote team member and trust that they are looking at the same thing as you, irrespective of their choice of platform. We'll need to come up with an alternative, probably web-based visualisation if Phabricator's commit graph really is gone for good.

For perspective we use commit hooks to ensure that commits made in patch releases must exist in upstream major release first before being allowed in the respective patch branch. We then utilize herald to notify a group about suspicious merges or commits.

In T12804#227133, @nickhutchinson wrote:

Equally valuable as "what branches contain that commit" is "what commits are in the branches we care about". For us, the answer to this is the commit graph -- it's a succinct, easy to understand representation of our branches and their relationships.

I get that if you only have one primary branch, there's not much value in the commit graph. Similarly, if you're not linearising history, your commit graph will be so messy as to be meaningless. But if you do have the requirement to actively maintain several releases of some B2B software package and have a well defined branching strategy for your team to make this happen, then the commit graph is meaningful and unexpected merges will stick out.

I'm not trying to be difficult - I honestly can't remember code that wasn't on one end of the spectrum (Or had the branching done by a single person, e.g. git), so it's hard for me to understand your needs.

(I've extracted the graph issue to T12840)

My two cents here:

• When reopening an existing closed revision because something is wrong
• When the diff has too much comments, even marked as done, it is extremely difficult to follow the code and/or latest changes. I suggest automatically hide done comments.
• When several people leave lots of comments, you answer them one by one by clicking the next arrow in each comment. Then the code gets reviewed again and more comments appear. It is a pain to go trought all the new comments as along the way you keep finding old comments. I keep going up to click and go to the next comment. Clicking next will just give me the next comment even if it is from old revision or already answered. I suggest to somehow have a thread on comments from the same comment action. So I can easily follow them without reading older comments or from others

This task is for Diffusion feedback, not Audit or Differential

Ouch, sorry for the noise. I usually get confused between Diffusion and Differential.
Keep up the good work.

Since the History is now dumbed down and separated from the Technical details on the Graph view, it might be more useful to filter out merge commits from the History view. Perhaps they can be replaced by a small "Merged to <branch>" link at the bottom of the box for the last non-merge commit that was part of the merge.

I'm looking at a repository now that has as the first 5 commits:

Merge remote-tracking branch 'origin/release/develop'

Merge remote-tracking branch 'origin/develop' into release/develop

Merge remote-tracking branch 'origin/feature/super-important-work'

Merge remote-tracking branch 'origin/feature/super-important-work' into develop

This is some actual work that was done.

This could be displayed as:

This is some actual work that was done
feature/super-important-work → develop → release/develop → master

In the past there used to be a Browse button at the repository homepage in Diffusion. Clicking on it would show the file tree for the current branch and some extra buttons. You could then click Search to grep the file contents of the current branch.

It turns out you can still do this, but it’s very hard to find: you have to open the branch selector, select the master branch that is already selected and then you’ll get to the page with the search button.

Maybe it would be possible to also show the search button at the repository homepage?

adding my vote to @ivo's suggestion.

I spent a few minutes trying to figure out how to get to the browse page as well - the way I figured out was to click on any file/directory, then on the repo name (above the commit hash).

Search is now in the header, see rP

Just for @avivey and his 11" macbook: D18448

Did you consider increasing the "tablet" breakpoint above the size of an 11" macbook instead?

I was joking.

11" Macbook breakpoint is 1080 it looks, I think we still do tablet around 960? 1080 is enough space for anything we do. Not sure where @avivey 's laptop actually is. I do want to add more information to blame view though, so the space will be used.

If it matters, my laptop is actually 13" with 1080, but it's only because the store said they don't have a smaller version.

I like the new design, but can I ask the oldness bar to be wider? Also, did the algorithm for calculating color change? It feels like there's very little range now:

it shouldn't have changed, just now a border. I don't know how to update the colors since it some sort of strange math only engineers know.

I could totally be imagining that.