The requests I've seen seem like users want this done automatically/by default, not that they want better tools to do it themselves.

Let's do both!

Maybe every object should allow a cover image then?

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

good stuff, thanks!

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

Maybe this was the workflow?

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

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

The button. That says Browse. 💃

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.

@jcox ???

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.

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.

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.

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

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.

Have a most recently accessed repo list in there somewhere. Right now the order is always listed by most recently updated repo shows at the top. Maybe a additional column in there that shows most frequented repos? or maybe a "favorites" list for repos. A user can have access to many repos but not use them frequently, so pushing them towards the bottom.

In T12804#226290, @sascha-egerer wrote:

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

GitHub, which has an omnibox

I find it really annoying how there isn't a real repository search (grep files) before you go click on "Browse". Generally speaking, search in Diffusion is very confusing with three different search fields in comparison to GitHub, which has an omnibox.

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

Or maybe even more specifically, I want to be able to tell a story on each commit in History. From start to finish every place code went or came from before it ended up in the repository.

😢

hahaha

Does it at least tell you how fast you're going?

I think I shipped this.

FWIW I partially implemented this in Wikimedia's fork, and I did so in a reusable way. I'd like to eventually upstream it but I'm not sure that my approach is desired upstream. I'll give it another shot though.

In this screenshot: