In D25022#24491, @Cigaryno wrote:

@speck if you think this thing works properly, you can either resign or click on Accept Revision, because when @valerio.bozzolan accepted the revision, it still appeared as Needs Revision.

• Improved comment

@speck @valerio.bozzolan @bekay Would you like to review this revision?

In D25897#24262, @aklapper wrote:

Thanks, I can confirm that this works as expected. :)
I agree biggest question is where to put this. In my opinion the UX is already slightly inconsistent (given their are also concepts like "Related tasks" in Pholio or "Referenced Files" in tasks).
In Differential it feels a bit like a stretch to put this into a box called Revision Contents.
In Maniphest the same "Mentions" tab is in the Related Objects box; there is nothing similar in Differential which already has numerous boxes (also Details and Diff Detail but none of those have tabs).

• Updates after review to wording and dropped the placeholders

In D25898#24255, @avivey wrote:

Also, I think that visually, the instructions are too close to the next field and too far from their own field, but that's far out-of-scope for this one.

I have also noticed this issue when submitting updates to a revision -

I found a method called setControlInstructions that adds helpful text above the field

• Refactored to use the setControlInstructions method on the control

I updated this revision so the title will only show the monogram if the user is logged in

• The title will only show the monogram when the post is public

Yes - it works seamlessly because if the local branch has a task number in it, the diff is automatically linked to that task when you run arc diff

Just adding references

In T15712#15124, @avivey wrote:

Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?

Looks like the tickets end in a Wontfix in https://secure.phabricator.com/T5301; I didn't follow the whole thing, but often the reasoning in Remarkup boils down to performance.

Just as a reference point, a few years ago, I created a version of this as well - It supports readCoverage coverage reports, etc.

Seems like it is solvable via

What is even stranger is that theoretically, php should not be able to exit with a status code of -1 - If you try, it changes it to 255

For completeness - Landing revisions from the UI Since they wouldn't be able to land from git? - Would have to be enabled in the UI

Could this be solved with a Herald action?

Just some notes for later

No errors in the console..

In D25129#4130, @Dylsss wrote:

In D25129#4083, @aklapper wrote:

Thanks for accepting. As I have been puzzled by arc for many years now, is there a way to merge via the web UI? arc land D25129 on a shell tells me that Branch "D25129" does not exist in the local working copy, likely because I've reset stuff here.

There is no way to merge from the web UI.

In T15096#3967, @valerio.bozzolan wrote:

One thing that could help a lot for my survival, for example, is the creation of a small bot able to convert the GitHub/GitLab flow to the Phabricator flow - automagically.

So, if I have a repository mirrored to GitHub in read-only, people can just do a pull request, and their stuff is converted to an arc diff, without any intervention from the code contributor.

I only warn that I work on it, because I need it for some personal side-projects hosted in my personal Phabricator - and where I don't want to yell at contributors who send pull requests from elsewhere.

D25015 was by @dcog If it can't be fixed with an update, this should be reverted

This revision is nearly impossible to test

Just a warning that I found a few bugs just by spot checking...

Hit esc today - Lost lots of typing

We should abandon this revision as secure has already updated their pem - see https://lch.lcdevops.com/rLCARCANIST13d3a3c3b100979c34dda261fe21253e3571bc46

• ran arc liberate

Here is the commit that introduced this

This looks pretty great! - I think T15030 is the general covering task for Extensions

This is related to or possibly a duplicate of T15011

I can confirm as well that I have never received an email from phorge / phabricator on my email which isn't "outlook.com" but is an office 365 email account

This is what the README says - And maybe we should remove support for the default.pem altogether? (But, possibly leave support for custom.pem)

Adding for refs https://discourse.phabricator-community.org/t/arc-blind-trusting-domains-and-cert-errors/4980/4

I would use arc diff

@Labricator Could you propose and submit a revision?

I feel like this is a good change. I do not see any security vulnerabilities that could be introduced by this..

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

Yes - I could have some availability - Normally evenings (US Central Time) -

@speck What can I help with here? - Are we waiting on upstream for anything currently?

Could you describe in more detail what this change is doing? - Because I am not familiar with celerity, I did read through https://secure.phabricator.com/book/phabdev/article/celerity/ for some background.

@Leon95 - I think this revision will be approved with just including the webkit alternate -

In D25015#826, @speck wrote:

I think that makes sense. Could you make a task to address this so we don’t lose track of it? Then let’s get this landed.

In D25023#827, @speck wrote:

Because of security issues related to this I’d like to have a verification of this type of change since this inherently defines the trust used by arc.

Maybe 2 core members independently verify the these certificate changes? Is there an fast way to verify the individual certs changed here?

Things seem wildly inconsistent for this particular css string https://we.phorge.it/source/phorge/browse/master/?grep=user-select

In D25022#774, @bekay wrote:

Then maybe just show the monogram when logged in.

I feel like we should move translation to a new revision, so we can move forward with this one.

I tested this revision on Edge just to make sure there were no negative side effects - No issues to report.

I am not seeing this behavior. (Using Edge)

This is a duplicate of T15051 and potentially solved with D25023

In D25022#768, @speck wrote:

Thinking about this a little more it could be intentional for these to not have monograms displayed in the page title. Tasks, Revisions, etc. are more meant to be directed to internal users of the system while Phame blog posts may also be directed to external users where a monogram might be more confusing. What do you think?

Referencing this "short" discussion that I remember from Discourse