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

The solution was to take direct children project and call $child->setParentProjectPHID($my_parent_phid).

Finally in my Phorge I can kill these milestones \o/

This is an issue in https://we.phorge.it/source/phorge/browse/master/src/infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php . In getObjectEmbedPattern(), preg_quote($prefix) returns \# and the method finally returns (\B{\#([^.\s?!,:;{}#\(\)"'\*/~]+(?:[^\s?!,:;{}#\(\)"'\*/~]*[^.\s?!,:;{}#\(\)"'\*/~]+)*)([,\s](?:[^}\\]|\\.)*)?}\B)u.
Within apply($text), $text becomes null after that first preg_replace_callback, so the second call barks.

Yep. In all cases it's at least a full-table-scan on file_attachment. Probably a bit more RAM-efficient with the NOT EXISTS thing since it does not need to have all file PHIDs in memory.

My userbase is stellar in relentlessly clicking every button you provide them :P

(Wow. I've never clicked on that button in my life, also when working)

Thanks :) Interesting weird transaction.

I'd be worried about DB performance running such a query as our DB has dozens of millions of files... (This is basically SELECT COUNT(*) FROM file_attachment fa WHERE fa.filePHID NOT IN (SELECT f.phid FROM file); in my understanding?)

Unrelated but @aklapper I'm curious about the situation in WMF. If you can maybe report something like this:

I haven't looked at Phorge's internals much yet, but perhaps the user could unmark a task as duplicate, or have the "Close As Duplicate" box be prefilled with the task that closed it and let the user deselect that and choose another one?

Once we remove this, we'll need to handle this edge-case:

• I've closed a ticket as "duplicate of T1", but I was wrong and want to mark it as "duplicate of T2" instead (and say it's not a dup of T1).

Partially related to T15822: When a phriction page is moved, history should follow the page move

OK. Well, thaanks \o/

In T15872#18251, @valerio.bozzolan wrote:

About this:

unset LC_ALL + LC_MESSAGES=C

I think it's not safe since other LC_STUFF can still be read 🤔

About this:

This [LANG=C] is supposed to be the default for missing LC_stuff

OK thanks! you persuaded me

LC_ALL=C is not risky on GNU systems.

A bit more than Normal, since it reflects on a database with orphan elements that creates "ghosts in the UI".

Probably OK now

Relevant old upstream comment (from an unrelated task) that describes this problem as "ghosts in the UI":

git config --global core.quotepath false

Posted question at git@vger.kernel.org.

I also faced this, tested @ D25623, and found out git format-patch was emitting that result which causes git apply to fail. See this git format-patch example.