The scenario in which this index would be needed is far from being normal. The patch D26027 that would benefit for it, is able to avoid that query in 99% of cases (it only needs such query when you want to destroy a profile picture, AND that picture was manually un-attached... why was it manually un-attached? by a spam click? by a faulty mouse?). So, the normal scenario is too small and unclear to justify a new index.

add extra inline comments about T16080

• implement review tips from @mainframe98 - thanks
• cover the edge case of a profile picture without attachments

Again, expanding a PhabricatorFileAttachment to support a destruction engine to post-pone its destruction does NOT work as intended (as it's still destroyed very after the file) since the destroyObjectPermanently() is always supposed to be executed BEFORE the extensions.

OK I've explored the proposal n. 1 about expanding PhabricatorFileAttachment to support PhabricatorDestructibleInterface, but I'm just moving the problem there. The attachment is still immediately nuclearized BEFORE the extensions can do things.

When you destroy a PhabricatorFile, it seems this happens:

It seems it's necessary to be able to "get the user from a profile picture". This is not easy, since the user seems not mentioned in any obvious way from the file object, as already stated in T15407.

Reword inline comment to be about our hero, Mario.

Can we also destroy the root project A? Sure! Added in the unit test.

Seems nice! Feel free to update.

Partial review, will conclude (I hope asd)

Plus, making the file editable by the author is the cure of T15814, so, moving that as parent task.

If we allow authors to destroy their images, we should also avoid 404 errors on them. So, the new subtask T16074.

Thaanks

(I just sorted the description to have the same order of the preview so it was easier for me to review)

Love this, thanks

looool double-slam-accept

My grep loves this

My grep loves this

e.g. https://regex101.com/r/PDyAGh/1 (then the slash, or the slash and the version - but that is)

There is something wrong now nearby the |((Chrome, that should be enclosed by pipes and just one bracket, like an hamburger of pipes, like @stuff|(Chromestuff)|(Firefox stuff)@0

@A_smart_kitten you are super-super-welcome if you create another parent task like this https://web.archive.org/web/20250218071010/https://secure.phabricator.com/T12486 so " Search exclude-by-tag doesn't work consistently with subprojects" - since I completely agree on your point but I'm unsure how to manage it, so here T15828 we become just one of your sub-tasks.

Triaging a bit more than "Wishlist" and a bit less than "Normal" since a prototype is actionable but we still lived years without this... so, "Low".

OK hackers, thanks for stimulating a follow-up. I've studied this a bit and I have a more clear opinion. Let's write some notes down.

P.S. Uh, I noticed that arc work also has a --start parameter! I documented a bit the expected behavior in the task T15993.

Tested for T15100 and T15993 and I'm a bit surprised to obtain, this very long branch with commas and square brackets (and just the closing bracket? uhm)

• arc lint
• arc unit
• fix a couple of id($api) and just use $api

Do you know for sure (did Fabio explicitly say so)

This is different than T15814: Files: reduce number of orphan transformed files

OK, tested by 3 hackers, no git regressions, more SVN stability, more inline documentation, more abstraction, very Phorgi, already tracking follow-ups, yuuup

In T15957#22436, @keithzg wrote:

Testing this a bit myself again, I discovered that actually this problem affects both Git and SVN

Thanks @Chlod for this bug report and please also enjoy T16057 and the new documentation table (D25988) that is provided to you for free :3