I'd like to see real use cases for this before pursuing it. In the use cases above:

Build also works fine if I submit it unmodified but omit the refs/tags/... prefix.

Only hit for "tag" is in this paragraph, which has no limits set (unless "empty text field" means "no tags"):

Here's a more granular transcript which suggests I'm not doing something goofy:

When I submit this:

Upshot: I'll do the thing that works for now. If we have tension down the road for the "code reviews intended for master" vs "code reviews intended for develop" use case, we can deal with it when it actually arises. It may be completely hypothetical. Users that did care could conceivably lift HARBORMASTER_BUILD_TARGET_PHID out of the environment and use Conduit to figure out where the review was targeted.

I guess there's also some amount of overloading here for "branch" and "commit", which is understandable since building tags/refs is rare.

This may be a bad approach, but one possible not-great-but-not-horribly-disruptive change might be this:

I think what I actually did was this:

Hrrm, I may be incorrect about that and have accidentally forced the tag to fetch in some other way.

Things seem to work fine as long as we pass the full path to the tag (we currently don't, since I'm reusing some CircleCI code and CircleCI, a lovely an inventive build system with many creative and original ideas, did not work with a full ref).

Let me poke at things and see how far I can get, there's a lot of future design space here that I want to leave open.

🐈

Because of the complexity of building a reproduction case and high chance that this is a wild goose chase, we'll move forward with this after a community member confirms it reproduces for them. See T12134 for some discussion. See T12129 for a similar recent report which was a time-consuming wild goose chase.

I'm working on this thing but it's turning out to be fairly involved so I probably won't have a diff for a bit:

I'll counterdiff you for these:

This was fairly straightforward since the Buildkite API and Harbormaster appear to have very similar models of the world. D17270 adds at least basic support. It uses webhooks, so you don't need to configure any post-commands. There may be some bugs or rough edges, so let us know what you run into if once you have a chance to try it out.

This also touches T10333: if you drop below card Z in group G (say, "High Priority" or "Assigned to alice"), I think intent is always to end up in group G even if card Z has moved from that group.

When you drop a card into a column, we send something like "alincoln dropped card X into column Y below card Z" to the server.

These aren't really related from a backend viewpoint, even though they're closely related from a UX viewpoint.

We're also assuming that you're red/green colorblind -- is that right? If you have some other kind of colorblindness, I think that would tend to explain why the colorblind changes made things worse for you, and I probably should not call the accessibility mode "Red/Green Colorblind".

• A very light "removed" color (default: very pale red) for lines which have removed text on them.
  • A more visible "removed" color (default: red) for lines which have been completely removed, text on lines which has been removed, and removed text in prose diffs.
  • A very light "added" color (default: very pale green) for lines which have added text on them.
  • A more visible "added" color (default: green) for lines which have been completely added, text on lines which has been added, and added text in prose diffs.

Do you want to give me four colors that work well for you as a starting point, by, e.g., control-clicking an existing diff and fiddling with the CSS?

Prose:

Better? Both just look grey?

Sorry I mean indigo

pink / slightly different pink incoming

@chad, I don't mind doing the legwork on this if you're OK with a separate mode.

I think we should just revert to the old colors and put a blue/orange mode in Settings → Display → Accessibility, since no one seems excited about doing the legwork in T12060 to pick other colors.

We recently darkened that color in T12060 to improve the UI for colorblind users, and the change was specifically vetted by a colorblind user (although maybe not a colorblind engineer who uses Phabricator? T12060#205789).

What version of Phabricator are you using?

I can't reproduce this. Here's what I did:

This is all frozen until we sort it out more generally.

is that expected for this?

We could do some URL magic in JS to add ?fullscreen=yes to the URL bar when you activate the fullscreen mode, then respect that. However it will take 75 hours.

sorry that our DEEP NEURAL NETWORK TECHNOLOGY can not yet READ MINDS

(I think this only impacts Diffusion, not Differential.)

For completeness, the "20 other subscribers" dialog displays disabled users in a different, unique way that isn't like any of the other ways (grey, no dot, no strikethru):

I'm going to merge this into T12164, which I think is a more powerful approach on this.

In Paste (and I think Differential), we scroll lines instead of trying to wrap them:

This task does not capture abuse cases. If you'd like us to build anti-abuse tools, please file a separate request describing the abuse you're seeing. See also T10215.

Particularly, see T9430.

Is that feedback based on the Audit dashboard at HEAD of master?