Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

In live comments, these links are bad offhand:

• The stuff above should be better now, but I'm not sure if I got everything. We should run through that list again.
• The "Subscribers" and "Projects" links here do not link to the correct domain, and fixing them isn't trivial because they're event-driven extensions:

Just bookkeeping, this doesn't currently have external priority.

Sorry, meant OAuth support instead of OpenID. The gist of it was delegate authentication to a dedicated system. Be it via OpenID, OAuth, SAML, etc.

Phabricator also does not support OpenID and we specifically declined to support it in T524#35252.

In T8787#177689, @siepkes wrote:

My 2 cents; I wouldn't spent too much time on implementing various authentication schemes for Phabricator like Yubikey, U2F, password with SMS or whatever flavour of authentication comes out tomorrow. Since Phabricator supports OpenID such authentication schemes can easily be delegated to IAM solutions like GLUU, OpenAM, KeyCloak, etc.

Now it might be a good idea to make a tutorial showing how to install KeyCloak with Phabricator to get U2F support but actually trying to be an IAM seems like a waste of time and duplication of effort.

My 2 cents; I wouldn't spent too much time on implementing various authentication schemes for Phabricator like Yubikey, U2F, password with SMS or whatever flavour of authentication comes out tomorrow. Since Phabricator supports OpenID such authentication schemes can easily be delegated to IAM solutions like GLUU, OpenAM, KeyCloak, etc.

Another possibility is that we just build this behavior (intercept and react to ref changes) as an extension point prior to the Herald, and then you can implement whatever magic you want. I suspect very few installs want the default behavior of git push origin mybranch for arbitrarily named branches to be anything except "create a branch".

FYI we'd mainly be placing devops engineers in the "allow push any branches" project group, so that in the case where we need to hotfix production, authorized users can create a branch in the remote to create a release from it.

I'd expect there to be either per-repository rules (like "Tracking Branches" for repositories right now), or Herald-based rules "on branch hook, convert to Differential Revision action" that would allow Phabricator to determine whether a branch is allowed in the remote or not.

So your desired behavior is that git push origin develop should create a revision, instead of creating a new branch in the remote like a normal Git repository would? How would users create new branches in this model?

In T5000#176433, @epriestley wrote:

non-master branches in the repository would be Differential Revisions

I think the closest match for this is T10691 (GitHub-like forking). I'd plan to implement forking very similarly to GitHub.

I don't plan to ever encourage users to create un-namespaced personal branches in the remote because I believe this process doesn't scale well to a large number of users. Much of the value of forking in my mind is giving users who want to do this (particularly, under the "git push = save changes" mode of thinking) a namespaced place to do it.

non-master branches in the repository would be Differential Revisions

To me, I imagined this task would be supporting something rather like:

You'll still need to go there and fill out all the stuff you would have filled out in your commit message. That is, this flow would drop you at the screen right after you copy/paste:

Write Depends on D123 in the commit message.

Phabricator doesn't give me an option to say "this commit depends on this other commit, so you can review it on its own but don't try to merge it yet".

If we are to support git push HEAD:review, I'd like users who are interested in this to explain exactly what they expect it to do, and why that's dramatically better than copy-and-paste.

Wow, good job! Check out your review at https://secure.example.com/D1234

In T5000#176361, @thoughtpolice wrote:

The expectation is basically, "I want to contribute a typofix, and maybe some more later, but why I do I have to spend 20 extra minutes up front on my first patch, a typofix? Can't this be easier up front?" Note that GHC is a compiler so it inherently has a somewhat high activation energy; this is 20 minutes spent on top of the 20-40 minutes you spent already getting it to build, etc.

So in the case of Haskell.org, specifically the Glasgow Haskell Compiler (which I'll go ahead and put out there, since I believe we're the one who got this put on 'The Queue' in question), our root problem that we think this fixes, I believe, is not "Phabricator should act like GitHub" or "Phabricator should act like Gerrit", which aren't reasonable or actionable as requests. They're sometimes brought up, but not our real problem. Rather, it is "Contributing smaller changes carries lots of unnecessary friction, perhaps even psychologically, because of arcanist".

IIRC, we copy/pasted at Facebook for quite a while -- maybe 6-12 months, circa 2007, before arc and related tools really got built out -- without ever running into wordwrap/whitespace issues.

My problem with copying & pasting are the media breaks: I have to format the patch, make sure it doesn't get mangled by some auto-wordwrap, trailing whitespace deletion, etc., and then paste it in or upload to a web form. git push ensures that I don't have to worry about any of that because the patch is an opaque "blob".

Git protocol rewriting appears practical.

The Git wire format for PACK data is very special, here's how you read the length of an entry:

@fooishbar, this task will not address your use case. We will, as closely as possible, implement arc semantics without requiring arc. The primary upstream motivation for this workflow is to provide a stepping stone toward arc which is as similar as possible to the arc workfow, not to provide a new, entirely different workflow which would make adopting arc more confusing and difficult.

@benjumanji history.immutable does not actually cover it, but this task is probably the wrong place to begin that entire discussion again.

If this is the outcome of you using arc land then you are doing it wrong. Just flick the history to immutable if you don't want it squashed.

In T5000#176256, @epriestley wrote:

(I am far less convinced of the value of forking or git push-to-review, except as onboarding tools).

Major unknown here is the complexity of decoding the Git wire protocol. The D9599 workflow goes like this: