The difference with our interface : I have not installed "http git" only ssh git

I cannot change the Space by default

I can't reproduce this. Here are the repository policies:

T10748, which provides the new cluster management UI for repositories, is nearing completion. This makes cluster setup more manageable and at least provides a pathway forward for Almanac stuff in the future, although it does not yet make Almanac / service management explicitly selectable when creating a repository (for now, new repositories allocate on a random open service).

We hit a couple of minor issues (e.g. D15856, D15865) in the last few days, but this seems to be working in production.

We don't appear to be affected directly and I've discussed this in the changelog now, so I'm going to close this out as I think there's no action remaining on our side. Let us know if anyone has questions, etc.

A very specific example of my confusion is the decision to place the link to the revision first in the mockup on T10283, and how it contrasts with the stated problem of triage efficiency:

(I think this is broadly similar to the original discussion on T10283, which also framed problems in terms of efficiency but also appeared to enable every inefficient/low-signal option available.)

As a thought experiment, if we sent one email per inline comment like GitHub does (and just repeated the author information several times in the body or something), I think that would technically satisfy all the points you raise:

This feedback is also sort of hard for me to understand.

Is metamta.can-send-as-user not configured in your environment? My expectation is that the mail comes "From" the user writing all the text in the mail, which makes it clear who they are. I expect that this information is normally prominent in the UI of most mail clients.

Haha, alright. You might be able to add it to conf/local/local.json manually as a workaround, but I'm not sure if that'll work or not.

After that action phabricator redirects to the main repo page. Is that expected?

AphrontMySQLDatabaseConnectionBase was renamed but I plan to remove this option anyway.

We iterated on the design a bit and ended up here:

@jcarrillo7, something in that vein will split out of T1460 eventually but we don't have a specific plan for it yet. I don't intend to address it as part of this task.

This is expected, and consistent with git's own definition of "mirror". The exact command we use is:

Inline comments are fixed after D15850.

I think I fixed this in D15847:

D15856 appears to have fixed this

This isn't the most thrilling UI but seems to get the job done. T10912 covers one minor followup issue.

This is getting somewhere functionally; we're going to iterate on the design a bit more internally.

Spacing/padding is definitely pretty iffy in Mail.app, at least.

My early-morning logic went something like "it's still there on disk so...".

That seems to be doing something fairly reasonable in my client, yell if it looks funky somewhere else:

I think this isn't really too bad. The major issue is that we can't use stylesheets in email because Gmail doesn't support them, so we need to emit markup with inline style attributes.

This is now live in HEAD of master, and deployed to secure. Here's phabricator/ on this install:

I'm going to call this resolved now -- there are still substantial rough edges with this and the rest of T10748, but we're running on the new code and everything else should mostly be UI stuff. T10922 has general guidance and I'll open an errata task to track cleanup shortly.

D15837 appears to have deployed cleanly here.

And I think the mail notifications are also largely reasonable, I just don't want to hack this one mail notification in and call it a day since this I think this should be approached more broadly (covering all high-security actions, not just SSH) and deeply (SMS, mail, transactions).

My only idea would be converting actions surrounding SSH key management to transactions, which you're not explicitly stating here, but if we were to do that we would be able to use internal infa we have that reacts to transactions, and send email when a key is added.

Some things we can do easily here:

I suppose we can trust X-Forwarded-Proto for the purposes of raising a setup issue, although I'm not sure if that would help here, since I think the header usually won't be set if you use nginx to terminate SSL instead of, say, an ELB.

We're extremely unlikely to pursue any changes where 99% of the time it works great and 1% of the time a user shows up here wanting to kill us, so arguments in the vein of "it would work for me and other reasonable users who know what they're doing", while likely true, has very weak persuasive power.

You can see which fields are copied in Edit Task → Configure Form → Using HTTP Parameters and scrolling down to "Template Objects". On this install, these fields are currently copied:

I suspect you may not be setting $_SERVER['HTTPS'] so Phabricator believes you are connecting over HTTP. It looks for a client using the http protocol, fails to find one (only https is available), and does not emit a websocket setup instruction.

A branch or tag can be moved from a very old commit to a new commit, and then re-run rules on a large amount of repository history.

Broadly, there are a class of "security" changes which are really policy compliance changes. For example, it's common for large enterprises to have a password requirement like this:

In T6522#173738, @reardencode wrote:

for (commit in commits_between(ref.old_commit, ref.new_commit)) {

I've generally been hesitant about making Phabricator send these emails because I'm not sure how valuable they are in practice, and a lot of users hate email (see T9161). If an attacker gains access to an instance even briefly, I think it's likely much of the damage is done before most users will be able to respond (in particular, a targeted attack can virtually guarantee you receive the email at a time when you are likely to be asleep). By its nature, this mitigation is a reactive one with a potentially long reaction time.

Per F1256292, presuming resolved until more details surface about what's up.