I'm going to declassify this too since there's nothing private.

Oh, you're right. I misread an implication of implementation specifics into "set", but the actual language doesn't actually suggest an implementation.

From above, I think there are really three use cases here:

And hg export is mostly the same deal as git format-patch.

T12618 could be accomplished by parsing hg log --patch --rev <rev>, which is similar to git show.

A maybe-less-complicated approach here could be:

(Although that gets into a whole other mess.)

We could reasonably give you the hash we expect the ref to contain, and should do this anyway as a correctness check to make sure someone hasn't --force pushed something else over it to do something tricky.

Given all of the above, why is repository.staging.ref provided as a Harbormaster build variable?

This isn't a good fit for the upstream.

Is exposing this information in conduit which Phabricator already stores that bad?

Today, how do you build any commit which isn't a branch head (for example, to bisect a bug to a commit which introduced it)?

This makes it impossible to build after branch heads move forward, but presumably you already have a solution for that or you would be unable to repeat builds in the general case.

So branch names are basically a key into a big map somewhere else which stores the actual complicated dependency information in a normal way and is probably backed by a file on disk somewhere?

(If not, how does OSv977 know that it depends on HTTP-v224, Scheduler-v416, Documentation-v84, etc?)

So when you cut a new minor release of your OS (say, v9.9.7), you go to every single library/project you depend on, cut a minor release there with the exact same version number, and create a branch with exactly the same name?

The state transitions are a bit tricky. "Plan Changes" temporarily sets the status to "Plan Changes", but does not "address" (internally, "void") individual reviewer state on its own.

I believe you can arc diff --plan-changes if your intent with (3) and (5) is to partially address feedback but not return it to me for review.

That is, the expected state at (6) is:

Oh wait. That is expected. The assumption is that the "one last change" in (5) is a response to my reject in (2), and that I need to look at it again.

That's not expected, but sounds like D17653. Did all the actions happen at rP517372a1?

Adding the file should fix this error, but we'll almost certainly break it again when we go to 800x800 without a test.

Basically, we routinely double the size of transforms. When we do, we also need to replace default-111x111.png with default-222x222.png so we have a fallback. We have failed to do this ~every time we've doubled things since it's impossible to know/remember, so getting test coverage seems like a good idea.

In D17295, we changed the "profile" transform to generate 400x400px images instead of 200x200px images. When we add or change a transform, we need to include a default result file for that transform which can be used as a fallback if the transform fails (most often because an install does not have gd, but possibly because of a corrupt image, inaccessible file storage, etc). That change didn't update the default result file, resources/builtin/image-200x200.png, so we were left with a 400x400px transform but a 200x200px unused default image that were not linked to one another.

Also javelinjs.com currently has bogus DNS, and there's probably no value in continuing to support it for the moment. I'll keep the bills paid on the domain in case we eventually revive Javelin as a standalone framework, but we could safely drop it from config.

I think the upstream actions are probably:

I suspect the reproduction steps are something like:

Here's what we currently have:

I'm going to kick this out of the ops space since none of this should be sensitive.

On mobile, I'd probably just keep this element in a fixed position on the page

@chad, some design stuff I'm thinking for later on, about in case you have feedback/ideas/objections:

I'm going to fix the editor behavior and then call this done.

I'm just going to merge this into T11401, at least for the moment. That may eventually split out into application-specific tasks when it gets underway.

If you experience this, please file a new task explaining what specific messages you're encountering and why hiding these messages is a better solution than changing the linters to raise more relevant messages. I believe fixing the linters is always a better approach here.

Actually, I'm just going to WONTFIX this. We may actually fix it, but I don't currently see a legitimate use case for it described anywehre.

My expectation is that the workflow in the task description will generally show this:

Actually, that description is a little misleading, but I'll follow up in T10607.

I'm going to merge this into T10607.

I can't reproduce this: