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?

Thanks! Now the second step is, finding at least one file that is related to the generation of the above feeds / texts

I'm not able to provide a smart title for this Task :D Thanks for any help in this

We can continue the discussion in Task T15556 - thanks for reporting

I currently don't have time to work on this so feel free to improve the diff (via arcanist/bin/arc patch D25296 / arcanist/bin/arc diff --update D25296).

Andre already has a diff already out for this...

Have replicated the fault.

• the setlocal isn't supposed to make a difference (it only applies the command string itself - ie if a file is named 🧆.txt.
• Setting E is more likely to cause this problem then to solve it...

I think these two are related here:

• https://secure.phabricator.com/T13060 (call setlocal in the master php process, so everything is always en_us)
• T15281 and https://secure.phabricator.com/T12071 (Env-vars are missing because of E)

(I'm able to reproduce. Had to apt-get install language-pack-hu for that...)

Is there a Task about this? if not, feel free to open that in Diffusion at least. I'm interested in seeing this fixed.

Ouch sorry renamed again since I forgot the discussion. Still an annoying bug and found your question.

It is on Diffusion > My repository > Selected commit SHA diff page. E.g. https://<domain>/R1:abdcdefgh

Where exactly are you seeing this error? what page exactly?