These are likely fine. The reason for preferring null check instead is if there’s uncertainty that the values could ever be anything besides null or string. The nonemepty string check might reject something that was previously accepted, where an object that overrides __toString would have strlen and friends operate on the toString function but the object itself is still used/passed. In this case I think it’s likely fine.

oop

The "Create Identity" button on /diffusion/identity/ should be guarded by this new policy access, though currently that form is not functional - see T15453

Split to T15453

I mentioned in the diff but the "Create Identity" page appears to be incomplete and the issues here and while it uncovers some additional PHP-8 issues after addressing them the functionality of this form would still be incorrect.

I think there's another issue here. I don't think this functionality is fleshed out and not an issue with PHP 8.1/2. On this install and others I get 502 gateway when trying to use the Create Identity form. I tried playing around with updating PhabricatorRepositoryEditEngine::newEditableObject() so that it assigns the authorPHID (the field I initially see being reported as not allowed to be null) so it's the current viewer. After doing that I got another error about the identity hash not being allowed to be null. Because of this I don't think we should update getUTF8StringFromStorage() here and just expect this form to blow up for the time being.

What is being referred to as "Public Contents"? Wiki documentation? Diviner documentation? Ponder questions/answers? Other than those I'm not sure that should apply.

Taking a stab at what it would look like in D25276: Add support for secure connections to the database. It's not tested at all yet but I think that's roughly the shape it would take. I haven't looked into how this would affect cluster environments but I think that is covered.

Is a database migration needed to update existing installs or will the default just apply?

Yes. The trade off would be user experience. I have absolutely spent 15+ minutes waiting for a reset email on sites after having either typo’d or put in a different email address from the one I signed up with.

As an approach this seems good to me. Would it make sense to put creating identities behind the existing Edit policy of the repository?

I wonder if this is related to not being able to use the Diffusion repository file auto-complete when not logged in even though the repo is publicly accessible.

Could you check whether your install is running with this change? https://secure.phabricator.com/D21676

Arcanist internally generates a diff that includes a similar suggested parameter to account for the entire file contents being present in the resulting diff.

From the exception

STDERR
waiting for lock on working directory of /var/repo/8 held by process '112297' on host 'ec6149cd0a0b/f000037a'

It sounds like another hg process is operating on that repo at the time.

Oh I completely misread your question, my mistake. I’m not actually sure what the data source query is.

Looks like create a brand new repository then navigate to it in Diffusion. I ran across this same issue.

I don't think this is an appropriate change, instead passing null into PhutilCommandString should be fixed. From the trace on T15367 it looks like a more appropriate fix might be updating ArcanistGitAPI::hasLocalCommit() to return false if $commit is null, or possibly updating ArcanistDifferentialDependencyGraph::loadEdges to check for null. I'm not sure under what circumstances it would end up with a null value though. In some basic testing the query it's doing does not return null for me.

It looks like upstream just straight-up removed the call to utf8_decode() in the master branch: https://secure.phabricator.com/diffusion/ARC/browse/master/src/utils/utf8.php$290-292

There is some support for this today, I have worked with dependent revisions in the past. There are some gaps but it’s possible today. I’ll look through my notes but I think this requires a fair amount of additional state tracking as commits change on local machines. I haven’t fully thought through it all but I think an ideal solution would be something like mercurial’s “evolve”, but that is likely a ton of work.

There’s possibly other reasons why they left it undocumented but it was a while back and I haven’t gone digging in the upstream for details.

Historically the reason why these aren’t documented is that they originally required installing 3rd party tools on the server. They were documented in tasks upstream but there was a security issue found with using graphviz so at that time out of caution they reimplemented figlet and cowsay in php rather than passing arguments to a 3rd party executable. After the implementation change documentation was never updated.

Oh I didn't realize it wasn't documented.

For a basic test additional compressed figlet font files have to be installed. I think it’s under src/support/figlet or src/resources/figlet or similar - pretty sure there’s a readme file in the location indicating it goes there. Then in a comment use remarkup to use figlet and verify it’s using the font you installed. For the zip check presumably you’d need to update php.ini to disable the zip extension.

We really need to turn on T15042 so diffs can be landed from the webpage

One other thing we’ll need to address is the current code sharing between arcanist and phorge. I’m not sure the full scope of what Phorge relies on from arcanist but I think there’sa fair amount. We can probably get an idea by looking at the libphutil repo which was the shared library between the two which was eventually merged into arcanist

I was similarly looking at lua for the same reason as it's used by neovim 😆 . There are a few libraries for lua in rust but the one that seems recently active is mlua, which doesn't implement lua execution in rust but binds to lua binary/library. If we go the route of binding to another library/binary then our build/package would have to include the lua library file too (though it may be possible to embed it?). Something like Rhai (or there's also Rune and a few others), are implemented fully in Rust so there's less to worry about during the build/package process. I wasn't sold one way or the other but wanted to check out Lua along with some of the others to see how well they turn out.

I’m fully aware of the friction that comes up trying to get developers using arcanist, the difficulties with PHP, the complexity in not understanding what’s going on, etc. and also familiar with the benefits of a compiled binary solution.

Hah this has been something spinning in the back of my mind for a while. One thing that will be difficult to support in something like Rust (not sure about Go) is that the PHP arcanist allows for very easily extending by dropping in your own PHP files to the extensions folder.

In upstream phabricator I worked with Evan to update the Mercurial API in a way that all mercurial commands/futures are executed through a common path and allow making modifications to only those executions. For this we should look at something similar so that we're only passing $HOME to git commands and not to others.

From https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html

Many people, myself included, contribute to open source projects under the assumption that my contributions will help serve a project which continues to be open source in perpetuity, and a CLA provides a means for the project maintainers to circumvent that.

Assumption here is key. The entire purpose of a CLA is to remove this assumption and clarify how contributions are managed. This post and disposition is based entirely around the organization receiving contributions will behave in an adversarial manner in the future. If the organization doesn't earn your trust then why trust them with your contributions?

Could you check the server configuration of php.ini for the value of variable_orders? This open task on phab suggests that on servers it should enforce including E causing phab's environment to be passed to sub-commands, but does not want to mess with it on users' machines.

Thanks for the thorough review

Thank you for making the update. I'll do some testing and likely submit this upstream as well.

I did some digging yesterday around PHP versions.

I've got a docker-compose setup working which runs mariadb and phabricator/phorge against shared/mounted phabricator/arcanist folders to allow easy local-modifications+. The readme outlines basic steps to get running. I've tried to keep it as minimal as possible while also making sure standard/default configurations are made so you can get up and running as soon as possible. Currently it's setup with php 7.4 but I'll be looking to update to 8.1 or 8.2. There are probably other minor things that I'll need to update with it as I use it more but I think this should generally work.

We have not migrated to using Phorge of Phabricator, so issues that crop up which are critical will be updates I submit upstream.

I wanted to set up some docker/compose file or possibly a VM but didn’t get far since neither of those are great solutions on windows, primarily for getting local code into the container/vm. My goal would be to get a quick setup time with a rapid dev/test cycle. For me to make progress I’ll likely have to switch to mac or Linux.

Getting set up with a development environment (including database~) along with configuring the local instance and populating it with sample data is extremely daunting and is frankly why I haven’t done much contributing. I lost my dev environment a few years ago and have tried only once to get set back up, spent a few hours and never came back to it. It doesn’t help that arcanist’s self linter isn’t usable on windows systems.

Okay real accept

Thank you for investigating! I think this is reasonable to land, given the investigation and testing there aren’t any immediate issues that seem to crop up on mobile.

From a usability perspective this feels nice to be immediately at something more useful. I would just try to find why the dashboard page works as expected but the main landing page doesn’t. If this change is still the underlying reason it seems good to me.

Does this change anything other than the landing page? When using mobile the first thing I do is click the link to dashboard and it shows properly there. Any idea why the home page behaves differently from the dashboard page?

Somewhat related - see T15050

Could it be cached?

Could you elaborate on what this would help with? I recall reading something in Phabricator’s past that the current url scheme is intentional as opposed to using the monogram/slug. I did a quick search and couldn’t find much, though in this change release
https://secure.phabricator.com/w/changelog/2015.51/

Removed dedicated titles/slugs. Phame posts now automatically generate readable URIs, but the slugs are no longer semantic.

We should investigate the history related to the current URL scheme before making a change. My suspicion is that it has to do with phase posts being “public” or published where having a url with part of the title is very common for linking across other content.