That sounds like a bug, but my guess is that the investigation would probably turn up "wow you are dumb at writing software" in about 3 minutes and not really get us much closer to a fix, which is probably "rewrite arc patch to fix 200 problems".

For (1), it's currently expected, yes. We don't create branches for dependencies in Git either, currently. I don't think this is terribly unreasonable, but I'm also not sure it's terribly useful (does it just help you keep track of which commits are part of the leaf?) and it makes cleanup more difficult by creating more total branch/bookmark artifacts in the local working copy.

D18152 should improve this: we'll still select the item as the default item, but will now render the navigation normally so the user can click other items:

Specifically, the issue is that multiple different priorities used the same keywords ("low", "high").

(That is, our behavior seems clearly incorrect.)

This just looks unambiguously wrong to me.

I'm going to modularize this, but not before the release cut.

Some of the (3), (2), (1) stuff is that we're trying to pick a single behavior which addresses most use cases reasonably well. For example, if we use "natural" bookmark names that will tend to make things much worse for users in bucket (3).

Thanks, that's much more clear than the original description!

(I think D18132 should fix this once someone gets a chance to look at it.)

I'm confused here -- the icons are already struck in every browser on my system (Safari, Firefox, Chrome):

This should now be fixed in HEAD of master, and promote to stable within about 12 hours. Thanks for the report! Let us know if you run into anything else.

A related issue surfaced recently. Actual use case (forensically reconstructed):

Oh, this is actually the Mercurial flavor of this action. We have this one in the Git flavor, which is why I was surprised:

My expectation is that this action can never appear -- this is the pre-Drydock hacky temporary action -- so something troubling is afoot.

See also T10005 (bulk editors for all applications) and T6722.

I think a minimal reproduction case which is typical of this example is:

That Throwable thing is fallout from T12855.

Ah, alright. Yeah, behavior is:

Oh, maybe I misunderstood. I thought you wanted an easier way to test changes in a development environment, but it sounds like you actually want end users to immediately get the new images instead of needing to wait 7 days for them?

A slightly more aggressive fix would be to make these have a 5 second TTL in development or something (or hash the file modification time into the builtin key? But that's a bit tricky...) so you'd never have to purge the cache, but I think this arises rarely enough that it isn't too valuable.

Strictly speaking, you still have to do a "manual purge" (with bin/cache ...) after D18146, but I assume you just didn't want to have to fish around in the DB.

I think this has never worked. This line came from D14652, but I don't think it worked before that either.

so smooth :3

It's good the world of art has people like us to make sure icons directly represent real objects in a 1:1 way.

I have reviewed these icons for literally representing true objects in a factual way.

Also not sure how to "retire" ones from Projects I don't intend to replace (low value).

If you want to move forward with that:

Great! Please mail support at support@phacility.com and identify which instance you're paying us for, then we're happy to help you. We won't help you here, since this isn't the right way for customers to get support.

Every repo host is equally affected, so I'd like to deploy crontabs as part of the regular deployment process if we use them as part of the approach here. That would require first codifying a handful of custom crontabs, including one on secure which regenerates documentation daily on only one host. This codification should happen anyway eventually, but it's a little bit of work, and wasted effort if we're switching to Chef/Salt/Ansible/etc soon anyway.

If you're a Phacility customer, please mail support at support@phacility.com (and identify your instance).

Why is git diff --no-index being used instead of and diff, and why is --no-prefix being used?

Here's another clue, from the relevant host's error log: