Ideally, comments are a general things and should be kept. Also changing Tags and Subscribers etc. is generic and should be kept.

Does anyone dare to accept the last revision? :)

The updated one-liner welcomes another review :)

Noticed a few dangling phacility references in URLs in documentation, which could lead users to grabbing upstream Phabricator versions by mistake:

phorge/src/docs/user/field/xhprof.diviner:  $ git clone https://github.com/phacility/xhprof.git
phorge/src/docs/user/userguide/arcanist.diviner:  some_install_path/ $ git clone https://github.com/phacility/arcanist.git
phorge/src/docs/user/userguide/arcanist_quick_start.diviner:  somewhere/ $ git clone https://github.com/phacility/arcanist.git

corresponding to:
https://we.phorge.it/book/phorge/article/xhprof/#installing-xhprof
https://we.phorge.it/book/phorge/article/arcanist/#installing-arcanist
https://we.phorge.it/book/phorge/article/arcanist_quick_start/#installing-arcanist

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.

did you find a solution for this?

Run arc diff from my computer that has Xdebug enabled

Can someone explain what these "Code coverage needs to be enabled in php.ini by setting 'xdebug.mode' to 'coverage'" messages mean ?
Are these automated unit tests run on we.phorge.it or on my system ?

Completely agree on lowering their ranking as default

@fgaz - did you find a solution for this?
For the "make Phorge extensions easy to install" feature (which I can't find the ticket for), I have a vague plan of adding another file describing available/installed extensions. I'd like to make packaging harder if I can avoid it, so possibly whatever solves local.json can solve this file too.

I have some containers I put together for development which could provide a place to start
https://github.com/neandrake/phab-dev

In T15566#14934, @valerio.bozzolan wrote:

I've just found again this

https://github.com/cooperspencer/phorge/

In T15673#14931, @valerio.bozzolan wrote:

OH MY GOD FOR SOME REASONS THEY RE-OPENED OUR PROPOSAL \o/ IT'S HAPPENING!

https://pretalx.fosdem.org/fosdem-2024/talk/review/EXZNAUXQKMJ7HRYYRD7MKFXTTV8JFQDJ

I do not remember who was developing Docker stuff for this. I've just found again this

OH MY GOD FOR SOME REASONS THEY RE-OPENED OUR PROPOSAL \o/ IT'S HAPPENING!

Just discovered this from secure dot, 2017

This works as long as getFieldValue() never returns an object (that has a toString, that may be empty)

Thanks. Don't take my comments seriously. Probably they have no sense.

This is exactly the same as I've done on the system I patched at my workplace. I apologize for not submitting my own patch, I didn't have access to my work systems during the holidays.

Hoping to be useful I've added you as reviewer in D25508: Add support for FIDO2-backed SSH keys

Some possibilities:

fix missing Transform entry

Also instead of “Goodie” maybe “Helper” or something. Maybe there’s a similar naming elsewhere in the code base

I forgot I had this requesting changes. Any idea of the performance hit in markup rendering now that PhutilURI is constructed for every link? I think its constructor does a fair amount.

You are doing a nice work.

Hi deric,

Alternatively, maybe catch the existing exception and show a nice error message + the form?

Still red light? Thanks :)

the simplest other-solution would be to extract the exception thrown to its own method, and override that method in the child-class:

How about other functions that might require a logged-in user? "current Viewer's Projects" for example?

In D25505#14525, @20after4 wrote:

Is this needed simply because PhabricatorApplicationSearchController doesn't actually have a try { } block to catch this particular case? Maybe we could improve the exception handling instead of return null?

Is this needed simply because PhabricatorApplicationSearchController doesn't actually have a try { } block to catch this particular case? Maybe we could improve the exception handling instead of return null?

Without D25505 applied:

Remove a forgotten debug line

This is not ready for merge yet.

Indeed ideally I'd prefer to convert the current use of PhabricatorSearchTextField for an integer value to a functioning PhabricatorSearchIntField (which should return a future new AphrontFormIntControl()) instead, thus I'm reluctant to land this (though it remains a mystery to me how to set a default value (not: placeholder) in any non-dropdown field).

Replace minus dash by its UTF8 representation to pass lint