FWIW is something like user.edit on the table? We'd like to be able to pre-create users with specific information such as 'real name', and a particular external account linked.

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:

This is in master and live on this install. Let me know if you hit issues with it, especially on mobile. Seems fine on my iPhone 4 but I don't have a ton of devices on hand for testing.

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:

Two of the three issues discussed above (lock granularity, severity of device enrollment) got tackled. I think I have an attack on versioning hosted repositories, but I'm not going to try to squeeze it in before the release cut today.

quick note: even on systems with 'normal' windowing systems many users
dislike or can't use drag-and-drop workflows. I'm mostly mentioning this so
that the non-D&D workflow isn't entirely treated as a second class citizen.

D15953 played out more or less as described above. I'm not going to land it before cutting stable this week since it touches Workflow in a couple of ways that might have unforseen consequences, but I expect it to be available in master some time later tonight or tomorrow.

After D12066, we have an upload workflow which gracefully accommodates very large files (progress bars, resumable uploads, no server host needs to handle more than 4MB of data on disk or in memory at once). This flow is activated when you drag-and-drop, and we've successfully used it to transfer reasonably-sized cluster import/export files (1-2GB) for the better part of a year now.

That cleanup stuff should be cleaned up now, so I'm formally pausing this for feedback.

In HEAD of master, keys now have a detail screen which shows a transaction record. Clicking the key name will take you there:

In T10939#176076, @eadler wrote:

I'm referring to the home page dashboard.

By this I mean: as installed on the FreeBSD install.

Ah! Okay, cool. Not really PEBCAK, I need to fix that dashboard too and it's super confusing that it does something weird/different with no clues about it. I just wanted to see if anyone caught major issues with the new one before swapping it.

I'm referring to the home page dashboard. I just made some config changes (particularly, changing the limit of the number of revisions to show) and it seems to have 'fixed it' so the problem above would be PEBKAC :/

Inlined patches are now highlighted more nicely in HTML mail.

The default is still

That's not expected, but I can't immediately reproduce it. Here's my local install, note that D4 appears in "Ready to Review" even though I (admin) am only a reviewer via project membership in Stonework (a project):

#twitter hat off. FreeBSD hat on.

Here's my technical plan on this:

Blocking reviewers can now be added, edited and removed via the web UI with the blocking(...) function. For example, entering blocking(epriestley) into the "Reviewers" typeahead will add epriestley as a blocking reviewer. You can use this to upgrade reviewers to blocking or downgrade blocking reviewers to non-blocking.

Sounds good (including your last comment). I think that from our perspective, we're it seems likely that we'll end up realizing a few problematic edge cases or details once we start integrating fully and it's probably best to wait until then than to try to gain perfect confidence ahead of time. The work done so far and what you outline in your last comment seems sufficient to start doing the integration work and we can surface issues as they arise.

I've consolidated the general state of the world in Audit in T10978. I think we'll run into some of that eventually but I'm not sure how much is important vs nice-to-have, so my general plan here is to just scratch the surface for now:

But a root owner's accept will still count for the sub-package, provided dominion is weak?

In T10939#175619, @epriestley wrote:

Just to make sure I'm understanding correctly:

(I'll restore viewer(), it's just not a one line change.)

In T10939#175557, @epriestley wrote:

Yes, since it would really mean exact(current-viewer) without additional work. Are you using it for something (dashboards?)

Just to make sure I'm understanding correctly:

In T10939#175518, @epriestley wrote:

• "Soft Accept" / "Unblock" action ("TBR").

The default home page (and homepage sidebar notification count) are also still doing the old grouping / counts. We should probably fix that but it's not a strict dependency here and there's adjacent work (T3583).

Yes, since it would really mean exact(current-viewer) without additional work. Are you using it for something (dashboards?)

I'm no longer able to search for "Responsible Users: (Current Viewer)". Is that expected?

Bucketing is now controlled by a "Bucket: ..." option in the search query controls instead of hardcoded as a behavior of the "Active Revisions" filter. This means that you can apply bucketing to other queries. You can also extend DifferentialRevisionResultBucket to implement your own bucketing algorithms (but: here be dragons).

(You can create an oldest-first dashboard yourself now if you prefer the old ordering, and can probably force it on all users after T4103 if you really want.)

This also indirectly flipped the ordering from oldest-first to newest-first. I'm inclined to retain that ordering, since it's consistent with every other application. The "oldest-first" ordering was a sort of paternalistic attempt to force users to review stuff, but I think we've generally moved the software away from that a bit and it doesn't feel very much at home to me any more.

I pushed that stuff live but bucketing has some bugs, looking into it.

Collecting some additional dashboard cases from stuff merged into T4144:

Packages can now be reviewers. They work very similarly to project reviewers. They can be added via the web UI or Herald. They can also be added via the CLI (by typing O123 as a reviewer or subscriber) but this isn't very convenient and I don't expect users to manually add them very often / ever.

In T10939#175260, @epriestley wrote:

Pretty sure D15918 is the right/expected rule: if you're an owner of "CSS" and "CSS" is set to "Auto Review: Review Changes (Blocking)", it doesn't trigger for your revisions: you don't need someone else who owns CSS to unblock your changes. Let me know if that defies expectations.

Pretty sure D15918 is the right/expected rule: if you're an owner of "CSS" and "CSS" is set to "Auto Review: Review Changes (Blocking)", it doesn't trigger for your revisions: you don't need someone else who owns CSS to unblock your changes. Let me know if that defies expectations.