It's not something we'll support given the cost and lack of interest. You can either fork and provide the feature for your local install or use a supported method of connection. To be honest, this is the first request I've seen in 5 years.

You must be able to view a post's blog to view the post, so the rule is effectively "view and edit".

Don't most places consider "Can Edit" to be weaker than "Can View"?

Historically, Phame originally used the claimed rule ("only the author"), introduced in or around D3694.

The rule we implement seems to work properly, but the UI tells you a different rule.

The language here is inconsistent with the rule we attempt to implement. Let me make sure the rule we attempt to implement actually works and that this is just a language issue.

If other workflows means pushing to the remote, T5000 is the plan. Functionally we don't feel " just push whatever" to the remote scales once you hit enterprise scale. The remote becomes polluted with junk branches.

@chad Do you have any hint for me how to configure a socket database connection

Thanks for the link. That's rather conceptual though. And things like overriding upstream landing is a thing that breaks compatibility with underlying SCM by assuming you use arc-feature. A tool specific explanation of the workflow would be great, for understanding the point of why things work the way they do. Though I'd rather the Official Workflow did not prevent other workflows. But I guess I have the power to remove that feature.

Alternately, follow T5000 for a non arcanist workflow.

@chad: arc-patch requires a diff and pushing a branch is much simpler than creating a diff. Since we seem to be pushed into the direction of an official Phabricator workflow, is that documented somewhere? Phabricator makes assumptions about code structure, versioning and many kinds of things, but are they stated somewhere?

It's abnormal in Phabricator. I use arc patch to work from multiple machines.

This is a problem for us too. People push branches to work on it on another machine.

Sorry I hadn't updated my worker hosts, you can close this as invalid.

Is that a bad url that's contained in the commit message? Is the commit message literally Change the recognised url from showcase://?ITEM_ID to showcase://item/ITEM_ID where ITEMID is the ID of the showcase item?

Oh I see. That's the problem. I tried repositor in the diffusion, it works well.
My fault, thank you guys. This task could be close.

I did't add my git repositor into Diffusion. Does that matter?

I can try checking if SSH compression is enabled later today (but I doubt it; I'm just using the defaults). Keep in mind the upload speed to Phacility is 8 MiB/s, it's just the download speed that's 100 KiB/s.

instead of git branch once could use arc feature which does (I think) basically the same, but gives hint about what mindset to use where.

The arc workflow is:

Have you tried changing SSH options on your end, such as disabling compression or using weaker encryption ciphers (such as arcfour, no encryption cant be done without agreement of the server)? This can make a significant difference with SSH transfer speeds, and may function as a decent workaround for now.

And here is the --trace information

I create a new empty project on my gitlab and clone it to local. And add .arcconfig file then commit it. After that I ran the arc diff command and it create a new revision on phabricator.
When I want to update the existing revision, I modify a README.md file and ran arc diff --update <Revision Number>. It's create a new revision every single time.
I'm using Mac, and it's the same on my mate's Windows computer. I don't know why.
Maybe I didn't configure currectly. So I want to know where was wrong. Here is my phabricator information.

That's the obvious solution, but I'm not sure it's practical given Phacility's infrastructure.

So probably, the actionables here are "Allow HTTPS in Phacility"?

It is for SSH - but compared with GitHub HTTPS it's much slower.

It looks like it's the same speed?

Final statistics are in after letting it clone overnight. Let me know if you need any more information to diagnose speed issues.

This is an issue specific to the repository names containing hyphens. The code is already calling calling the correct sort functions.

I created these repositories:

I am unable to reproduce this problem given the instructions provided:

That change fixed a lot of bugs, so we aren't going to revert it: reverting it would break all the things it fixed and added test cases for. --no-index --no-prefix diffs have never been part of the test suite and it is just coincidence that it worked before that change.

--no-index - diff is created outside of repository by comparing directories.
--no-prefix - I'm not sure about this - some historical reasons and code in the service which generates diffs. But as I understand this was supported since D3744 and until rARCd0957c344156356123048be2219fb95a54c89a85.

We don't maintain that instance. Please contact llvm.org directly for it.

Yes, this is expected. The process of converting a project to become a parent project can not be undone:

This behavior sounds correct to me.

Glad I could help! Thanks for getting the fix in so quickly!

I believe your analysis and proposed change are correct. D18177 brings that change upstream. It is now available in master, and should promote to stable later today (within about 12 hours).

This should now be fixed in HEAD of master and promote to stable later today (within about 12 hours). This change hasn't been deployed to secure.phabricator.com yet but will be deployed no later that tomorrow morning (about 24 hours from now), at which point the example link you provided should start working.

Firefox iOS seems fine

Testing upload from Android with Chrome:

I don't believe we've ever supported Firefox on mobile. Do you have the ability to use a different browser? Or are all browsers on Android non-operative here.

Please don't test this server. We will disable your account.

Probably resolved.

At HEAD of master: