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.

I queried the production backup log to find the maximum size of any active instance's backups to contextualize decisions around backup and storage management in D18094.

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

Comments are fine.

Clicking "Cancel" after starting an inline comment leaves "0/1 Comments" in header. (do you want tasks or comments for these issues?)

Conveniently, bin/restore already exists and does much of the above, although it doesn't have a --download flag yet and its current behavior is to abort if data already exists.

Actually, from the logs above I didn't even do it manually and just made it up for no reason.

Thinking about this a little more, there's really no reason to do any of the rebinding stuff until after we move the data. I did that earlier when moving manually, largely for convenience -- but we don't need to sequence things like that when automating, particularly if we don't need bin/storage to work on the new database.

I think we have a generally tricky situation on the database stuff here. The general algorithm this process is using so far is:

This is because of the synthetic comment from Lint near line 108 of DiffusionHistoryController.php, not because of the comment in the screenshot.

(That said, GitHub does show an accurate count so who knows. Maybe the page is slow because they aren't doing anything stream-oriented. In this case, a directory with 3M files probably just crashes.)

I also suspect that GitHub compromises here for performance. If you look at a very large directory on GitHub, it shows only the first 1,000 files fairly slowly (page takes 1-2 seconds for me) with no pager, and a warning that the directory is too large:

The reason this isn't trivial is that we ask git, hg, or svn for a list of files, for example with git ls-tree.

yes I believe you have been coaxed into a clever trap -- and your predicament is of your own making!!!

Please see Contributing Feature Requests for instructions on how to file a constructive feature request.

This will help

I’ve been catfished.

Yeah I just realized this isn't a front end change, I got to trace it down to the source.

I'd offer assistance with testing mercurial on a large repository - but the largest repository I have doesn't have more than ~50 items per directory (that I'm aware of~), so I don't think it would hit the stress points you're looking for.

oh

👍

(Poems doesn't have an example of the first kind of directory, and I don't know of any offhand, but you could build one locally in a couple minutes I think.)

Offhand, I don't know if the kernel has directories with a lot of files in it or not -- like, Phabricator itself probably has only 1-2 directories with more than 100 files (resources/sql/autopatches/) and might have none with 100+ files and directories, so you could implement this wrong (pick the first 100 paths, then sort them by "directoryness") without there being any counterexamples in Phabricator. It's possible the kernel is the same.

Is poems the best example or do you have another suggestion? I can try the linux kernal.

Or, specifically, a list of files like this:

(That is, more than 100 non-directory files.)

I don't care too much.

@epriestley Do you care if I just flip this. The hypothesis being folders are clicked more than files, and having them first makes more sense for me, and in our case, brings them above the page fold currently for rP.

I'd probably pass on the preference, I think folders should just go first. My main observation here is if you instrumented clicks of folders vs. clicks of files, folders are probably chosen 2-1, my expectation here is that people have to dig down first, then open the file they were looking for.

In T12144#226158, @epriestley wrote:

Why would you want to set those up as milestones instead of subprojects?

It doesn't help that GH/GL Milestones are loose tags with a target date.

We could also let you collapse/expand columns like your mock in T6642. None of this hide/show/filter/collapse/expand stuff is hard -- T11036 and T4900/T10336 are the only really involved JS changes in queue for workboards, I think. It's largely just not clear to me which subset of the proposed tools is most useful, and it feel like major overkill to implement all of them.

But it's mostly moot until T11036 I think. T5024 is vaguely related ("filter to just one column"). T6642 might be related ("save collections of columns") but my recollection is that task was a bit muddy? I haven't re-read it recently.

That's very easy, just a question of whether we want to add the buttons/menu items for it.

Yeah there are some UI tweaks I can do to dissuade accidental milestone creation.

What about workboard filters? View Milestones, View Subprojects? That sounds like a lot of work though. Might be nice on large parents.

One minor fix would maybe be to put "Create Subproject" first on the "Subprojects" page. This is inconsistent anyway -- the tab is called "Subprojects" and the header is "Subprojects and Milestones", but the order in the action column, the curtain panels, and the main panel is "Milestone, Subproject". I think this stuff blame to me in D15152, but "Subproject, Milestone" is probably a better order both for consistency and to gently nudge users toward the more general / less specialized unit of project division.

I don't think this should be a language problem or that "Milestone" should communicate "flexible target" -- physical milestones are big, immovable, evenly-spaced chunks of stone with a single increasing integer chiseled into them. They're a really direct metaphor for the behavior of milestones as implemented in the product. But feel free to send me a diff to swap it to "Iteration" if you think that's clearer, I'm not married to "Milestone".

Maybe it's a language problem. "Milestone" to me says "target" so I think it's a fluid set of targets that may or may not be in an order.

If anything, a hypothetical "Progress" tab should show ALL subprojects and only a SUBSET of milestones: just the last, current, next, and maybe +2 / +3 milestones. If your work is really linear and time ordered the progress of the milestone from five iterations ago isn't relevant most of the time.

That is, milestones largely exist to support future features that depend on a linear ordering, like "push all open tasks to next milestone", automatic creation of the next milestone from typeaheads, automatically scheduling milestones sequentially for charting/reporting, etc. If we let you reorder them most of that stuff sort of goes out the window (or, at least, gets much more complicated). And if these features aren't actually important, I think we could possibly just remove milestones from the product.

There's no technical reason we can't let you reorder milestones, but adding features that let you bind milestones to time ranges may be much more difficult if we let you reorder them.

I'm still ok with allowing people to re-order milestones, hard to imagine we'll get reports asking for it to be restricted.

I think that's conceptually reasonable, but I can't come up with any reason offhand that it should be restricted to milestones instead of showing both milestones and subprojects.

I was considering building a formal "Milestones" page which listed all the current milestones under a parent and their respective progress.

Yeah, I'm pretty sure there's no difference.

What behavior do milestones have that subprojects lack (or vice versa) which is relevant for progress tracking?