I was able to reproduce on this install by passing rPf712ae718ccc1c94d882c626ca8626b77346026b to the Herald test console.

OK, so I just manually removed the branch from info/refs and packed-refs and I think that maybe that worked?

In T9028#180932, @joshuaspence wrote:

Ah interesting. From our GitLab host, I see that git branch --all shows a whole bunch of local branches and only a single branch of the form remotes/origin/url_shortener.

Ah interesting. From our GitLab host, I see that git branch --all shows a whole bunch of local branches and only a single branch of the form remotes/origin/url_shortener.

In T9028#180926, @epriestley wrote:

Hrrm -- is the repository a non-bare working copy (e.g., has files and folders in it instead of just config/, hooks/, info/, etc)?

OK, running ./bin/repository discover --verbose rX gives me a bunch of output including this:

Updated our Phabricator install just now. One issue I discovered is that we are having a bunch of audits triggered for commits that are newly discovered. We have Diffusion configured to track only the master branch, but now Diffusion is importing commits from all branches, it seems.

Ah I see. So for the "create ticket" workflow, it only seems to happen when creating a ticket from a workboard. In this case, I do not see the button go disabled.

I was able to reproduce this on a Phacility test instance as well: https://test-ftzenxozitfe.phacility.com/phriction/edit/?slug=/

I am using Chrome on Ubuntu, but I don't think k the browser/OS has much to do with it. I'm guessing that you can't reproduce it because you have more internets than I do. If you can artificially throttle the connection speed then it might be easier to reproduce.

Would it be possible to prioritize part of this ticket? Specifically, the use case mentioned in T10627? We are also interested in the ability for members of a project being able to create subprojects without requiring global "Can Create" permissions for Projects (I thought that there was already a ticket for this somewhere, but maybe not?)

This seemed to fix the issue:

From the server logs:

Phabricator version is rPe1ad312fdd2c570eeaacd3e02eda2142cc5d9849.

The following queries are full table scans:

I don't know how to reproduce the issue, but figured I'd let you know that I'm seeing this in our error logs:

Yep, works now. Thanks

I'm not sure if this change is correct, but it seems to fix the issue for me: https://secure.phabricator.com/differential/diff/38381/

I think the output format from differential.parsecommitmessage has changed:

Oh, this is probably the correct error log:

Server-side, I have the following commits deployed:

In T10939#175557, @epriestley wrote:

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?

FWIW I have updated to Ubuntu 16.04 locally and haven't had any issues with Arcanist.

This is my Aphlict configuration:

(It's quite possible that I am doing something wrong here)

Yep, that works. I didn't realize that null was a possible return value.

Ok thanks. I found it very confusing.

Why not change Phobject::__isset and Phobject::__unset to throw an exception in the same way that Phobject::__get and Phobject::__set do?