Thank you so much for giving me help here. Have a nice weekend. @avivey

It's based on git-grep. You can't give it any arguments.

Wow, that's great.

https://secure.phabricator.com/diffusion/P/browse/master/ - there's a Show Search button, that will let you search by filename or file contents.

Thank you so much for the help. Now it works.

Looking at the first image, it looks like the symbols are defined to be cpp symbols; That would fit your description of the behavior:
When searching from the search-field, the system ignores language of the symbols; When looking from a source file, it narrows down the search to files of the same language - in this case I think it should be swift.

Ugh.

Is fulltext set on the field?

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.

Can you tell us what you're specifically trying to accomplish? As requested I don't know what problem this solves.. See Contributing Feature Requests for more information.

To further elaborate:

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.

To install:

Alright, let me sketch out the "missing X account" thing.

For the "you don't have external account X linked", it might be easiest to just fork and implement it as an extension that pops a notification bubble? I can give you an outline of how to do this, but I don't think there's really much to gain by providing a formal extension point since you just need a one-liner in PhabricatorStandardPageView, fork-wise. The downside to this approach is that you could only dismiss it by linking an account (dismissal of the HTTPS warning would be impossible, and dismissal of the timezone warning would not be generic), but maybe that's fine.

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

Maybe a good way to attack this is to discuss specific notifications. I think the use cases we're aware of are:

Yes - my comments were meandering in nature. Sorry, should have made that
clear.

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.

Our main interest has to do with "please fix your timezone" and "please link your external accounts". That is, action oriented, high priority, requests. The FYI or MOTD style prompts are secondary.

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.

This should realistically wait until the we get rid of the old default homepage and everything is driven through dashboards.

Something somewhat related potentially depending on the implementation you'd imagine is "bulletins". Where you have a user base, and as the operator of the system you want to communicate something to folks in the tool where it's relevant (for example, to aid discovery of a new feature that was added that we think people want to use, or strongly suggest a best practice etc).

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.

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.

Would definitely like the ability to swap out the eye via config à la wikimedia install.

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

thx

See discussion in T4190 for tips on implementing this locally.

What does arc which say before you run the final arc diff?

Yep.

This is T418.

I think the "root issue" here is "users want to easily distinguish revisions by repo in the search results".

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