A git commit is a user-initiated event that may be processed synchronously. It is unclear why interaction with a daemon would be necessary to support a suitable user experience.

Another problem dramatically frequent for newcomers (at least in my office).

You should be more reluctant to make critical comments, especially as you're obviously not familiar with the project or its history (hint: it was never a commercial product).

Yeah you are describing a problem that is affected by a system administrator decision, not by a limitation of the underlying system.

I recognize that Phorge is a community effort inherited from an earlier commercial product. I am reluctant to make comments that may seem critical.

Uh thanks! Feel free to increase the "Hours invested" counter in the Task description ihih

• background tasks: Phorge needs a "traditional service" that runs forever after its startup
• databases: Phorge for scalability reasons needs 60+ databases :) :) :) circa one database for each component (like one for Ponder, one for Diffusion, one for Maniphest, etc.)

a php 8 fix

Ok, I got bored.

I understand the objections, and the realistic constraints.

I'm going to open this question's visibility, and also answer your questions here - in the hopes we can put this issue behind us.

I wish to repeat my earlier request that the issue would remain open and visible.

I don't see file F281219

ah, the original intention for the second query was "even if the diff is closed", circa 2015. Back then, it was probably not possible to update a diff owned by someone else, so it made sense to add the withAuthor..

I was finally able to read the code and understand what's going on here.
The original code is strange, and the withAuthors() part in it is definitely wrong in context.

I don't remember how to explain things to humans

Tested, works, thanks :)

I'm not sure if I understand your question.
I thought the fix was already implemented by aklapper?
What do you want me to do?

In D25021#10296, @avivey wrote:

@kwisatz maybe file a new task / re-open the old one?

Do you want an help to land this? (No problem, in case)

I think we have an implementation:

(Implementation notice: in both phorge and arc, this is handled in PhutilErrorHandler::handleError(), and the check is simply $num === E_DEPRECATED), and maybe E_USER_DEPRECATED.

I also tried going outside running:

@kwisatz maybe file a new task / re-open the old one? the screnshots are not unreadable, but if its bad enough that people complain then maybe we can find a solution.
Didn't somebody invent "webfonts" or something, so we can just package Segoe-UI and know that everyone is getting a decent view?

My plan is:

• If there's a commit information in the revision, use the author name and email from there. Not that this might not be the same as the revision's Author
• If there's no git commit - use author name from Author field, and make up email address (annonymos@example.com).

@avivey Yes I think this is what we need.
There is a caveat though:

@ton - this is what I have so far:

This one-line change is a present for my friend @Matthew

In D25355#10291, @valerio.bozzolan wrote:

How would you describe the syntax of this?

So in short this just assures that the current item is shown.

How would you describe the syntax of this?

Interestingly, I think arc unit didn't find any tests to run... I triggered this explicitly.

D25355 fixes the jshint test.

I've patched the branch and ran the tests on Linux.
Of the 6 failed test files (13 tests):

• 1 fails in master (ArcanistJSHintLinterTestCase)
• 2 are skipped locally because I don't have the external binaries (ArcanistJscsLinterTestCase, ArcanistRuboCopLinterTestCase)
• and the rest pass with these changes

I have this working now in https://we.phorge.it/D25276. I still have it marked as draft because there are some outstanding things that should be decided/addressed

1. Whether client certificate should be configurable. Ideally this is something that would be configured in the php.ini rather than directly in phorge but at the moment I don't think it can be.
2. Updating documentation to specify how to set up TLS/SSL. For database configurations there's now a use-tls flag which will require connecting to the database using TLS. Turning on TLS/SSL on the database we can probably provide pointers but it's left to the reader for determining that based on their database.
3. Database clusters with master & replicas? I don't know how to set this up. Those changes might affect cluster dbs but I'm unsure and it's untested.

To be clear - it's a single file in a single commit, in the equivalent of this page: https://we.phorge.it/rARCa604548101025875de20a9c263df3790fea425b3 - is that right?