The upstream pathway for this lies beyond T182.

Oh, I think I misremembered and it does foreground by default. You can use --background to improve performance, and monitor from /daemon/.

Note that index --all queues stuff into the background, so you may need to wait a while before it finishes. You can use --foreground (slower) or monitor progress from /daemon/ in the web UI.

D14370 likely fixes this, although I don't have ElasticSearch 2.0 locally and haven't tested it. I'd guess this will give you a clean bill of health:

Can you show me the output of this command?

I think the discussion is in T8090.

I think that should clear the way for you, let me know if you hit issues.

D14368 should fix the issue where you're required to set a dummy "Also Clone" repository.

Yeah -- that make sense, I'm just want to be mindful of how much complexity we're adding to the upstream in order to subvert barriers that have no technical reason to exist.

"Lease Host" is not currently expected to work at all. It hasn't been updated for any of the changes, including authorizations. "Lease Working Copy" (under "Drydock") should.

Drydock is a prototype and all of the Harbormaster build steps which interact with it are prototypes. Much of this code has been substantially rewritten in the last two weeks. See:

If you do this:

Can you show me this?

FWIW this would be useful in repositories where users can push branches (and maybe only to certain regex-matching branch names) and not tags.

There was one more followup in T3855 to fix a couple of bugs, but if you updated this morning you probably picked that up.

D14365 should fix that too, now. Landing in a sec...

Cool, that's an easy fix.

Ah, okay. If we put a no-op "--ff" in that command, does it overwrite the configuration option and work locally?

Let's look at your second one first since I think that's a little simpler. I can't immediately reproduce it. Here's what I did:

I think that will fix things, let me know if you run into more cases.

After D14361, the new behavior is so complicated that I don't think I can briefly explain it, but very roughly:

This is just a big mess to resolve in the general case because we need to identify a path from whatever was landed to the remote, then cascade changes down along it, because there may be an arbitrary number of local branches between the target and the remote.

Yes, that's what this refers to:

oh come on you're just making up new workflows at this point

I'm planning to leave this open since it also contains a lot of discussion about Mercurial and none of the recent changes affect Mercurial (particularly, they do not resolve the branch/bookmark issues). Of relevance here:

(Let me know if I missed anything, and thanks for the report!)

This does mean we can't distinguish between these cases:

That does look like a bug, let me take a peek.

In your advanced workflow, you could sort of work around this by making sure your local branch always has a different name than the remote branch.

This behavior is intentional and I don't plan to change it.

I'm going to merge this into T9132, as any pathway forward here runs through that.

I think this is fixed by D14357, although I'm surprised by the original behavior. Here's what I get after D14357:

D14357 fixes this. The new behavior is to recursively resolve upstreams until we:

I think we will probably build such an application eventually, but I doubt we'll build it until 2017 at the earliest (i.e., it is at least a year away).

In general, see Planning / Paid Prioritization / Roadmap / Starmap.

In Git, after D14356, and ignoring any bugs, arc patch D123 && arc land should work (it should already have worked, just not preserved author metadata?).

After D14356, we ignore the local branch (if it exists) until we've pushed.

Oh, sorry, D14356 doesn't actually fix this.

This should work after D14356.

After D14356, arc land will preserve authorship and author date data. Since arc patch also preserves them, the net effect should be preserved authors.

No clue how to repro, no reports in nearly a year.

About an hour.

Yes: move it into the "Contract Fix" column on the Dropbox workboard.

I'm going to close this out as I think we're generally in good shape here and we're now hosting builds and doing server-side lands in the upstream, and don't anticipate much more Drydock-specific work in this iteration.