T6102 and the downstream also contain discussion of a second case which does center around exact matches -- searching for "Wikidata" -- but I can't reproduce it at HEAD:

D15981 doesn't, strictly speaking, prioritize exact matches. However, it should fix the underlying issue.

You can test with "Discovery" at https://phabricator.wikimedia.org/

Almanac Blueprints aren't mentioned downstream but I think are also a fairly good fit for this:

Yeah, I don't think this helps at all if there are 50 results, but I don't think we can do anything about that. Better solution is to fix the workflow somehow (nuance, subprojects, etc).

The original use case on the downstream task (https://phabricator.wikimedia.org/T234) was this:

I can remember trying to file a bug against Safari when I worked at Apple, seems like a simple task. But typing "Safari" came back with 50-100 tags... I had no clue as a first time filer what to fill out. A short description might have helped, perhaps. But overall I guess I'd like to understand what users are ending up at the browse dialog to begin with. In the Safari case, having something like Nuance is better for the novice user than asking them to wade through 50 results and guess the correct one. I want to basically make sure we understand which user we're helping here.

I think users are probably mostly only using this UI to browse things anyway, so it's likely OK to "slow it down" a bit visually, since that could make it easier to navigate if we save users from needing to go look up information in a new window.

I worry overall that this will compound the issue when installs have too many projects. That is, if they already have hundreds/thousands of projects, doubling the information makes the UI twice as large and difficult to navigate through. Maybe one idea would be to only show additional information optionally (via a checkbox) or only after results start to get filtered?

My plan is to put an on-hover (always available on mobile) edit icon on top of the thumbs on the edit UI, similar to how the interaction works on workboard cards:

Copying in some context from elsewhere:

I think nowadays the biggest issue (as it is the most work to manually correct afterwards) is two folks editing a task description at the same time and silently overwriting.

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".

Great, thanks! (And with clarity I meant instant visual clarity for people who haven't been involved in designing them)

I went with checkered for now.

@chad Do I understand you correctly, there would be just outright white background for transparent areas with your patch?
The checker background gives clarity as we have to make sure that many of our interface elements shown in Pholio mocks are working on dark and white backgrounds.

Git protocol rewriting appears practical.

I'm more inclined to remove the checkerboard outright from view. The main concern here is if it's confusing on the edit page, then it's also confusing on the thumb and embed views. The only place we use checkerboard is on the full view page itself.

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:

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.

Not sure if this was just a test or not, but it's doesn't look like a bug report. See Contributing Bug Reports for help writing good bug reports.

This is an invalid task here, but in any case https://phabricator.wikimedia.org/ does work, also for anonymous users.

D15942 restores the project tag transaction to the first mail about an object:

I guess this originally had several different parts. My thinking on the parts are:

or that

Better to do the header tags in the body text thing?

I think we're mostly unsure what we want to do here.

Is this task open to be Prioritized? Wikimedia is discussing the possibility to fund it at https://phabricator.wikimedia.org/T135327

Tagging Wikimedia - This task would resolve a regression we experienced after having moved from Gerrit/Gitblit to Phabricator Diffusion as primary repo browser. Gitblit, similar to GitHub, rendered .md files as Markdown by default. (Remarkup would be fine, too.)

We're prioritizing the research to estimate how much work this is so we can possibly eventually prioritize it, so this is going into the queue, but don't read too much into it.

In T5187#175015, @epriestley wrote:

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

See Paid Prioritization and L34 Phacility Prioritization Service Agreement for specifics, if you haven't run across them yet.

You're behind T10917 and T10939 in the queue (see the Prioritized workboard) and some other things which are wrapping up, so it will probably be about a week before we can pursue this. If that sounds reasonable, we can get this into the queue now and confirm with you before starting work.

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

@epriestley I'm happy to try to pay you to review the patch if that'll help.

(If that answer isn't particularly satisfying, maybe see discussion starting here: T7820#172877.)

We haven't seen much interest in this from outside WMF, so there are probably several hundred tasks ahead of it on our natural roadmap.

This is still a big problem for Wikimedia's Phabricator installation, making it unnecessarily difficult to file or amend bug reports about mobile issues.

@epriestley thanks for the extra context. Makes sense now haha. Sad to see this get deprioritized though.

This was moved into the prioritization queue by a particular customer that was interested in defining Owners via Projects via external sync.

@epriestley can you explain how this was building up toward T10939? That one deals with automatically adding reviewers while this enables project membership (and hence policies) to be based on a predefined source of truth at most companies (LDAP).

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

https://phabricator.wikimedia.org/T129049#2242513 was quite easy to do using iceweasel on debian on android 10" tablet. It involved moving the task from Backlog to the last column which wasnt visible on the screen. This might be more difficult with larger workboards, but there are definitively scenarios where this is painless on a tablet, and is a natural UI for the action on that type of device.
I wonder if it is any more difficult on high res smart phones in landscape mode- I suspect it might work quite well also.