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.

Severely needed. .arcconfig should be able to control where things land without arguments. I also question the choice made in D10058 where branch tracking seems to be used as a indicator of a branch created with arc-feature. Since arc-feature is in no way central to arc use, I think it should not be assumed that it will be used. And regular workflows and GUI tools will use git-branch instead, with tracking.

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.

Synchronously in the request. I'll look at adding logging.

If you go through the process manually with the web UI, are the versions OK after initial creation? After adding an observed URI?

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:

So I'm not immediately able to reproduce this. Some possible questions:

I used this parameter bundle to create a repository:

I'm attempting to reproduce this from the web UI first. I created a new repository, and get 0 versions as expected:

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.

You could probably add a route for the icon in apache/whatever manually if we're hyjacking the request

That's what I suspected (I did find the rsrc link, but it seemed a bit suspect, and my default setup doesn't serve it anyway). Thanks!

In my personal experience, CloudFormation is vastly better than Ansible/Chef/insertflavourofthemonthtoolhere. Those other tools all require some specialised syntax, meanwhile CF is just JSON and you can use the CloudFormation designer to get the JSON for any AWS resource that you're not sure how to describe with JSON.

Parsing hg export metadata is an elegant solution. # HG changeset patch could imply sourceControlSystem = 'hg'. Thanks for merging the task!

The background is the Mercurial community wants to try Phabricator as an experimental review system. It's using emails now. I'd like to make Phabricator workflow as convenient as traditional email workflow.

Thanks for the reply @chad.

I'm writing a Mercurial extension to send changesets to Differential like hg email provided by patchbomb extension.

There is no secret tracker with a different set of priorities or timelines
for features. Everything we plan is 100% open. This feature is not on any
short or medium term roadmap and you can read Planning for more
information on how we build the roadmap. We do plan to offer paid support
soon which will let installs prioritize features they need.

Hi,
My small team & I have been using Phabricator for a year. This is the feature that we lack and that makes our day-to-day work difficult. It would be nice to have even the basics (drag & drop to a column -> update to a given status). Any advise or workaround in the meanwhile would also be nice if they are some. Sorry if I lack Phabricator knowledge and missed an obvious workaround feature.

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