I personally prefer option 1, so, removing the duplicate body. So there is more creative space to then add a more useful body in the future.

This is becoming quite frustrating in my workplace in Torino. Let's start immersion mode.

At the moment we have a multi-thread command existence checker, and it early dies if a command is not existing.

Cannot reproduce (or I misunderstand the steps):

1. Created https://github.com/aklapper/emptyrepository for testing
2. Went to phorge.localhost/diffusion/edit/form/default/?vcs=git and created emptyRepo.
3. Went to http://phorge.localhost/diffusion/26/uri/edit/208/ and set URI's I/O Type to Read Only
4. Went to http://phorge.localhost/diffusion/26/uri/edit/ and set URI to https://github.com/aklapper/emptyrepository and I/O Type to Mirror
5. Went to http://phorge.localhost/owners/paths/1/ , edited/removed existing path by setting it to: Include R26 emptyRepo / , and clicked "Save Paths"

The word solution would solve it from the expecting side, you are right. Here in my company the search is used frequently and only as a plain text search. So we have to escape the special regex signs time and again. Just would be interested if this is seen as an issue by others who uses the feature.

We can probably add a checkbox, and some nicer handling for the exception. Or possibly, just adding the word "regex" might solve this from the "user expectation" side.

Thanks for the clarification. I still think we should tackle the exception.

The word "pattern" was meant to imply "regex pattern".
Specifically - the ability to search for a regex is much more useful then a plain-text only search (and costs us basically nothing).

In T15728#15768, @valerio.bozzolan wrote:

I tried to understand the situation. Thanks.

In your opinion: on the repo view (with clone buttons) is it really important to link to the other similar "reduced" view (without clone buttons)?

I tried to understand the situation. Thanks.

I have landed my solution.

In T15645#15201, @speck wrote:

@bekay while in this area of code would you have any pointers on these other issues I’d like to fix at some point?

1. File browse widget doesn’t work unless logged in, for publicly accessible repos
2. The search results pop up width is often too narrow to show the full results path, and truncates the end of the path instead of beginning.

@bekay while in this area of code would you have any pointers on these other issues I’d like to fix at some point?

1. File browse widget doesn’t work unless logged in, for publicly accessible repos
2. The search results pop up width is often too narrow to show the full results path, and truncates the end of the path instead of beginning.

@speck @valerio.bozzolan My revision is ready to be tested 😄

https://we.phorge.it/source/phorge/browse/master/src/applications/repository/storage/PhabricatorRepository.php$348 got fixed by rP222a6fea0a1d9318198fe73a0501cf6444420ce3 in T15658, thus resolving

Under the hood branches are already supported by the locate feature. The whole file tree is loaded via AJAX, when you first click in the input field. This tree represents the current selected branch.

I’ve been meaning to investigate this. It also has thrown me that it’s not available where you expect it. I do suspect @valerio.bozzolan is right

I wonder if under the hood this means "Add branch support to Locate File"

Well, no opinions from the team. I still think this should be implemented... 😁

you just adopted PHP 7.4 or something similar I think to fix

Thanks for reporting

Nevermind, this is a problem with my setup, sorry for the noise. (I missed the second line, and of course I realized it right after submitting)

Yeah feel free to review D25301

I still like this. Why is this not going forward? 😄

This is now resolved.

In T15583#13304, @avivey wrote:

go for it.

There may already be a feature somewhere to automatically trigger a re-index because the code changed - I'll try to look for one this week.

edit: looks like it's just "add an autopatch" like resources/sql/autopatches/20191028.uriindex.01.rebuild.php. No worries.

This might be a Good Starter Task, I think - you'll need to add a class for the config, and pull the config value in diffusion.

go for it.

Okay, my proposal:

a hack that might work: add a field in the document that's called "typeahead-text" or something, and put both title and callsign into it (and maybe number and short-name as well). Then use that field in the Datasource.
Since this is a full-text field, whatever the user types will fit this field...

Okay, I have tried to wrap my head around the ferret engine. Problem is: the repo callsign is not part of the indexed material. So I would have to construct some query like (just a schema): WHERE ferret-query like '%term%' OR callsign like 'term%' - but that is not possible with the phabricator query engine. The ferret query parts are separatly created and every other where clause is merged with AND. I don't think, there is a clean way out of this. You could make TWO queries: The old one and one with the ferret engine. And then merge the results and remove doubles. But I don't know... just doesn't feel right.

In T15583#13296, @avivey wrote:

I suspect that the code in People is the oldest one - this stuff blames to 2011! and does explicit sql stuff!

rP99c9df96b4ffbf7 (2015) is the big "convert to Full Text Search" commit, but looks like it's not about Ferret (2017?).

I suspect that the code in People is the oldest one - this stuff blames to 2011! and does explicit sql stuff!

I have searched through the code a little bit and there is another system for typeahaed results. It is token based. So, how does it work?

Yeah, that's probably good - that's the query for typeaheads and probably global search, but not for other cases.

There is no ferret involved in my fix. I have already implemented it in our company instance and the devs are loving it. The change is in this line: https://we.phorge.it/source/phorge/browse/master/src/applications/repository/query/PhabricatorRepositoryQuery.php$650

I also don't fully understand the "Phabricator way" to create full text queries still using indexes. That is my main concern.

Yeah, totally reasonable feature request.
Do you think you can implement?
This might involve the Ferret engine (like this thing, or maybe there's a simpler approach for the query (title LIKE %text% in the Query class?).

No interest in this? I can send a diff to differential and be mauled there 🦁

Just to illustrate my point - here are the repositories of phorge: https://we.phorge.it/diffusion/

Cool, I'll play with it and see what I can find.

Okay, I think I created a minimal example reproducing the problem. The repository is publicly available here: https://sourceforge.net/p/tinloaf-phorge-problem/code-hg/ci/default/tree/

Do you know off the top of your head whether the binary-detection in the commit view and the code browser view differ in some way?

To be clear - it's a single file in a single commit, in the equivalent of this page: https://we.phorge.it/rARCa604548101025875de20a9c263df3790fea425b3 - is that right?

To be clear - it's a single file in a single commit, in the equivalent of this page: https://we.phorge.it/rARCa604548101025875de20a9c263df3790fea425b3 - is that right?