Chrome 109 on Windows 7
No JS errors in console

Does not reproduce to me.
Which browser are you using? Are there any javascript errors?

Would taking care of the depreciations bump the minimum PHP version required to run Phorge?
looks good to me otherwise

Yeah, the dialog looks better then the extra notification...

I like so much this popup, thanks Roberto

In T15349#13341, @valerio.bozzolan wrote:

I don't know how to add a third button in a modal, but I would agree on that approach.

In D25416#11982, @valerio.bozzolan wrote:

Tested, seems good to me

To land, please do this from your side:

arc patch D25416
arc land

Thank you!

I don't know how to add a third button in a modal, but I would agree on that approach.

Tested, seems good to me

In D25374#10923, @Matthew wrote:

Please fix unit errors

fix lint

This seems the exact backward-compatible thing to me

Maybe we can improve the current popup from current:

But it adds another notification, and now the user will have to pick between 2 buttons that say "solve conflict".
It's also not the common path - in the common case, we expect users to actually approve the timezone offered by the dialog (which should be the one detected from the browser).

0. Welcome!

1. This diff is based of a commit that's not in master - some local changes that make it not-apply
2. the space should be on the inside of the pht(), not attached to it.
3. even better, find whatever is calling describeAutomaticCapability(), and if it accepts an array (some implementations return array, some return string), have the caller add a space between each element of the array - solving this once for all callers...

In D25420#11967, @avivey wrote:

Adding another notification will only make this more annoying.

Why not just improve the current dialog to make it easier to ignore the conflict?

Adding another notification will only make this more annoying.

Argh, sorry for my comment. I missed that rPbcfcd9acfc12fdf8ca3bf0e2c89651ba6d159b17 removed that noise already! (Anyway, I cannot share a stack trace when no stack trace is printed anyway.)

@aklapper Can you please share your stack trace?

@valerio.bozzolan: This is now spamming our error logs. Any recommendations how to proceed?

Thanks. I would like to help in reviewing but I don't get the difference. Can you describe the inline change?

Updating D25419: Fix the whitespace issue in the message "Access Denied: Restricted File"

Updating D25419: Fix the whitespace issue in the message "Access Denied: Restricted File"

fix a typo

Please do note that this patch is untested as I am unaware of reproduction steps.

Hi @bekay, I think that D25408 fixes this problem

shrug

Try again, after an rm and arc liberate on master, and then a git rebase master on this branch

and that's now wrong because src/__phutil_library_map__.php includes a non-existing file though I had ran git stash. I love git...

Obviously not a clean tree, sorry. Thus ran arc liberate, now arc asked whether to include unstaged changes in src/__phutil_library_map__.php (yes)

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.

I don't love this, but this is a general fix:

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 🦁

Ran arc unit first

Make code more readable

Accept whatever stuff is passed as $label as long as it's not null, per last comment

IDK - this was code was never explicitly about git am - I think it was about patch, which started in the stone age and predates things like "formal specification".

I will kindly mark this as request changes since unfortunately we have a crash if the $label is an object like PhutilSafeHTML.

In D25359#10790, @valerio.bozzolan wrote:

I noticed that Phorge exports the date in this format:

Date: 2023-08-02 23:23:38 (UTC+2)

While git exports the date in this format:

Thu Jun 29 23:23:28 2023 +0200

Is this known? Should we uniform these?

Thanks again \o/

OK so if I understand correctly:

Lint