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:

I can't remember which ticket, but I remember a similar discussion regarding arc patch (whether arc patch should patch onto HEAD or pull from the staging area).

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:

Because this works from the staging repository, it will be possible to trick it right? I mean, I could do this to sneakily commit virus.exe to the repository:

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.

For now, I just asked him to change the policy to a custom policy consisting of users X, Y, Z.

In T9648#142020, @epriestley wrote:

Can you see the repository? (PHID-REPO-rgnn364lembo2emt5622)?

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.

Can you see the repository? (PHID-REPO-rgnn364lembo2emt5622)?

OK, I have asked the author to add me as a subscriber... but I still can't load the page.

I received an email regarding the revision:

This is in reasonably functional shape for ambitious users. There's some documentation now:

Probably not, but it seems vaguely nice that i18n extract doesn't need to know anything about the directory structure, and that we can put pht() in externals/ as a local patch if we need to clarify some error or something.

Is there any real news to extract translations from externals/?

@Krinkle: I can't come up with a reasonable way to fix the height=300 comment preview case unless we render the element entirely on the client or relax the WMF constraints. I think the WMF constraints are excessively paranoid, but it's moot since you're the only person complaining about this and you're on the WMF install, so adding a "[X] Use less paranoid caching that doesn't flicker all the time." option wouldn't fix the problem for you.

Ah OK... I can't rememberif I had set a height when I observed this behavior.

• With height=300, yeah, it's going to be a flickery mess.
  • Without height=300, it's a flickery mess in Safari only, in the last few weeks, as far as I can tell.

I'm fairly sure that I've observed that behavior in Chrome.

I'm pretty sure the preview case is recent (last couple weeks) and I don't think we changed anything, but I haven't hunted down what actually did change. My theory was that it was a change in Safari behavior, since I don't see this behavior in Chrome and I first observed it after applying an OSX update. Are you using Safari in OSX?

Yeah, I'm on Android 6 and it seems to happen consistently. Yes, as far as I know Chrome on Android hands off downloads to the "Downloads" application. Steps to reproduce are basically:

Some discussion in, e.g, T9028, but we don't plan to ever actually delete these commits. They may have comments, audit status, meaningful relationships to other objects, builds, build artifacts, etc.

This is because externals/stripe-php/lib/Stripe/ApiRequestor.php has this on line 357: