I'm not sure what is being suggested.

• test with object

• flip condition

In D25326#9469, @valerio.bozzolan wrote:

Maybe we can pass also an object that has a __toString() method

Explicit is better then implicit.

In D25325#9466, @valerio.bozzolan wrote:

Yeah but I don't see that readability bonus point here since we have a "not non-empty" condition.

In D25325#9464, @valerio.bozzolan wrote:

I mean, so the goal of the cast is to be able to operate strictly with strings, so finally we can if($v === '') without any pitfall

• More test cases

(looks like most other custom fields already override this method with something useful).

I'm pretty sure that any place where strlen is getting something that isn't a string (including int), that's actually a bug. In Phabricator code, strlen was only supposed to be used when expecting a string or null; All the places we now find aren't strings, are places where we were wrong about the type of the object.
Epriestley says something like that at https://secure.phabricator.com/T13588#257329 .

I've added both links to the preamble for easy discovery.

• Feature request: https://we.phorge.it/book/contrib/article/feature_requests/
• Bug report: https://we.phorge.it/book/contrib/article/bug_reports/

1. This is a feature request, it should be defined using Feature Request pattern, not Bug Report pattern.
2. We already implemented this in D25035

I don't think I intended to land this change.

Also, this mashes up Diffusion and Repositories to add confusion

Oh yeah - you can even host it here under Phactory: Community Projects (if you want to and it's open-source).

Did some digging, and it looks like it would be more involved - it would require adding support code in the query engine (like Spaces), and making another DB call (Flags are their own objects), or re-implement Flags using Edges.

DO you know about arc browse?

It's enabled by default - https://we.phorge.it/source/phorge/browse/master/src/applications/people/config/PhabricatorUserConfigOptions.php$48

The task had a heavy dose of "describe a solution, not a problem", so I cleaned it up.

more cases

I've enabled OAUTH using Github.

"experimental" means "not really working yet"... When it's fully usable, the "Experimental" label can be removed.

How would we as phorge upstream use the info? Would it inform development? Be just informational?

Sorry, I still don't understand the footer part.

Starting from the end:

1. It's not called "Flavored Markdown" - that's not a complete name. It's either "XXX-flavored markdown" or just "markdown".

1. It's not called "Flavored Markdown" - that's not a complete name. It's either "XXX-flavored markdown" or just "markdown".
2. Fix the test plan in the description.
3. what's the deal with the footer? What does it do?

To create a DB, you need to add a class like this one to your app:

• update the test plan

It's an infra issue, but it's our infra :(

Formally "requesting changes", but only for the inline SQL code. Everything else I said is just "a suggestion".

Showing project tags might be unique to tasks - Revisions don't show them, and neither do Owners or Commits. It might make sense not to show it here either.

1. Please move the "what is GHFM" chapters into the task.
2. I'm updating the title to be more descriptive of the change itself.
3. Instead of manually testing, add test elements into src/infrastructure/markup/remarkup/__tests__/remarkup/

I'm unable to reproduce:
I've deleted a file in arcanist library, and ran arc liberate. I got no error message and the __phutil_library_map__.php was updated correctly.