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/

Inline issues should all be fixed.

• Mention ./bin/repo edit workflow as eventually deprecated by Conduit
• Fix indentation
• Validate user values for repo hosting modes

• Mention ./bin/repo edit workflow as eventually deprecated by Conduit

This should work fine. boolean "should" queries do basically exactly what you'd expect.

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 ?

We could probably do better than string, but that's what the index was doing during automatic mapping creation anyway so I figured the status quo was ok for now.

Should be be ready other than that last inline bit.

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

This should probably be rebased on top of the work in D10955: Properly create Elasticsearch index.

Implement recursive settings comparison to check index sanity

Refer to init in check instead of init-index

• Cleaned up base class implementations
• Switched auto_expand_replicas to 0-2
• Made things work better for non-english installs:
  • Dropped english posessive stemmer and english stop words
  • Swapped english stemmer for kstem

Replies inline.

Change checks to happen with other site checks instead of at index
time. Introduce new ./bin/search init for initializing the index.

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)

In D9202#50, @csteipp wrote:

We can just use whatever url the user inputs (maybe suggest they use the script path, /w/, etc), but then mobile redirects don't work.

We could add an optional parameter in the setup, which asks for the optional url to redirect the user's browser to, and suggest a /wiki/Special:OAuth url. If the user fills it out, we use that for the /authorize url. Otherwise we just use the one url they gave us?

In D9202#47, @20after4 wrote:

The /w/ and /wiki/ urls are the default and recommended mediawiki configuration:

https://www.mediawiki.org/wiki/Manual:Short_URL

One issue is that the plugin only works with mediawiki.org when it uses /w/ and /wiki/ in appropriate places. I'm not sure how to make that part configurable without making it sorta confusing...

@csteipp can you offer any suggestions here?

Handle uri formation better, don't add to deprecated config, call the
setting 'namespace' so it's more clear to Phabricator.

I went ahead and signed the individual CLA since I retain the copyright on all my work.

Just tested against a fresh build of v0.90.9, worked just fine still.

It should, but I'll double check.