Per IRC, for posterity: it's a combination of implementation detail for our fetches at WMF, as well as seeing this done: T6878: Tagged commits which are not ancestors of any branch head don't get imported

In T4292#143345, @paladox wrote:

Is there any way on replicating from gerrit to phabricator like refs/changes/

Ah, I think I had 2 PullLocal daemons running and one of them was fighting while the other was doing its job. All seems fine now.

Well the daemons were failing with the same message. I tried running it manually to see if phd was at fault at all. Same stacktrace either way.

Here you go: P1698

In T6887#90318, @chasemp wrote:

In T6887#90317, @epriestley wrote:

Is it possible that the affected repos are being imported by creating a new hosted repo and then pushing to it, versus using "Import existing repository"?

I don't think so but let's ask @WikiChad ?

Thanks for getting this so fast, we'll be sure to pull this into our next deployment.

Thanks for the quick turnaround on this!

Sounds good. I'll work on disabling it in our install anyway :)

It's not disabled on our install (should be, but that's our issue). Was just following the links :)

Actually, we can work around this quite nicely after talking with folks. If auto_create_index is set to false, we just need to create an empty index and it'll figure out the mapping when the first document is inserted. In ES speak, it's just issuing a simple PUT to the bare index that doesn't exist yet: curl -s -XPUT <es-host>:9200/<index-name>

No, nothing incorrect about your usage, just need to detect the scenario and error out properly. There's two workarounds:

• Disable the setting completely, create your index, turn the setting back to how you had it
• Configure the setting to whitelist the phabricator* index and blacklist the others.

(for a bit of background: we've got this set to false at WMF because ES has a bad habit of not creating indexes exactly as we'd like them so we don't trust it to and have an index-creation script ourselves)