See T9530.

As is sometimes the case with legal issues, I think this request is based on a misunderstanding of the law. The German "Telemedia Act" establishing this requirement ("Telemediengesetz") does not seem to require the link to appear on every page.

• Remarkup areas got inline previews in D14855.
• EditEngine got some extensions to restore similar on-page previews to Maniphest.

If we put spaces on user accounts, how do I get into a Space you have permission to see so you can add me as a Manager on the payment account for phacility.phacility.com in Phortune using the typeahead?

We use (most of) the graph code for drawing the "Task Graph" and the "Revision Graph" so we need to keep it around in the upstream anyway.

This is fundamentally unfixable

("Graph" button in upper right.)

https://secure.phabricator.com/source/phabricator/history/master/

I think that's what D18131 did -- or do you mean something else?

This is fundamentally unfixable:

I think we're more-or-less at the point where the existing Nuance code is about as internally modernized as it's going to get, so there isn't a great deal of remaining obvious technical debt to pay down.

At HEAD of master:

This is "fixed" by the associated series of diffs, in the sense that the actual problem (being unable to delete web UI config) is fixed. This is remaining work:

See T12874. Your account will be disabled if you continue creating tasks like this. Follow the instructions you were given.

You can find tasks with no owner by searching for "No Owner", like this:

They already --prune when pulling:

For private reasons affecting the reporting install, this no longer has customer impact.

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:

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.

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?