Just for some micro-optimization, note that preg_replace() has a 5th parameter called $count

I can confirm that this patch fixes the string problem. However, I am super super puzzled that after applying this patch, the CSS definition line-height: 22px for .phabricator-wordmark is suddenly missing in both Chromium 120 and Firefox 120, moving the wordmark a bit higher in the upper left corner (on my two screenshots, that is "Phoriorge").

I assumed that $this->newStringIndex($value) in the next line implies a string here but let's play safe, indeed.

Right, makes sense as I do not fully know the internal logic.
As PhabricatorStandardCustomField is generic, also keep null check type-generic

The only trouble with maintaining a separate arcanist package is keeping the version in sync with phorge. Phabricator never followed anything like semantic versioning and there was never really any stable api version to depend on. Perhaps we could think about versioning and release cycles that follow a more predictable major version release cycle with API compatibility guarantees. It is certainly more convenient (for the upstream) to avoid all of that but it offloads quite a bit of burden on anyone trying to use the software.

TLDR; I think @aklapper is on the right track: I did some more digging and it looks like something similar to P24 is probably the only reasonably easy solution.

Phacility was very much against this kind of things, but I actually favor supporting some packages, at least for Arcanist on the big package-managers - if nothing else, it would allow us to make sure the package with the right name is doing the right thing.

Feel free to review, in case:

Unfortunately they have not accepted our proposal in the track Collaboration and Content Management. I've proposed that again as Lightning talk as suggested to me by FOSDEM ex-speakers.

I keep arcanist cloned in /home/kuba/bin/arcanist. /home/kuba/bin/arc is this executable file:

I've managed to land the diff with arc --config-file ~/.arcrc land

do you have an entry for "https://we.phorge.it/api/" in your ~/.arcrc ?

Abandoning as superseded by rP1c098c273d06ea3cf8215245ea109f41c59593d9 (which first requires commandeering)

also, arc get-config hosts --verbose - but note that it will actually print out the tokens, hide those.

That's odd...

• do you have an entry for "https://we.phorge.it/api/" in your ~/.arcrc ?
• I'm also confused about the --trace not including any comment about loading any configuration source - that's probably a bug
• how about echo {} | arc --trace call-conduit -- user.whoami ? in the phorge dir and in other dirs?
• I'm assuming /home/kuba/bin/arc is a symlink to arc that's in ~/Downloads/arc?

Also, commands like arc patch and arc diff --update work fine for me, it seems that only arc land is affected.

• Better syntax highlighting

Running with --trace gives me:

The highlighting process could track elapsed time and stop highlighting any further documents after a fixed amount of time elapses...

Thanks for the note, Andre! I've went ahead and updated the revision as discussed above.

• Add spaces in HTML message builder instead of to each item text

fix PHPDoc (last version v2.4_final3_really51.zip)

(In the meanwhile, removing the red semaphore, since the goal was to attract reviewers and it worked asd)

In D25419#12616, @waldyrious wrote:

Should I go ahead and submit a different patch? Or could I somehow contribute the edit to this patch?

I totally agree with these additional considerations. Thanks.

Since I can, thanks to that revision, at work I've put this additional CSS rule for extra nonsense scary climax.

@aklapper you are now a member of Blessed Committers.

fix PHPDoc

Since this was vetted by epriestley and previously by myself as well. I think that it exceeded the minimum standard for code review before it landed here.

Here's another one that I think deserves to be upstreamed: https://phabricator.wikimedia.org/T230787 adds context and search term highlights to fulltext search results. Currently Phorge and upstream Phabricator only show matching document titles with highlights on keywords in the title but not the body.
The efficiency of my solution is questionable, however, it's working well enough for Wikimedia's use of the feature.

• add dedicated class to handle things
• add interesting test cases
• ready for dinner

For better syntax highlight feel free to adopt ,lang=ini in the code block. So, the line becomes:

Thanks!

I really appreciate this, and I can confirm that this systemd service is almost exactly the one I have in my production. Premising that in my production I've added also:

Partially related, a systemd unit for the SSH server. Proposal in D25497

Thanks, it was just a docs typo fix, so I ran the arc diff command with the --nounit flag

Since we already show the full (public) key when editing, then I don't see a reason not to show it after it's revoked.