This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.

Can you create a document on this install which you believe should have a table of contents but doesn't?

This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.

Copying in some context from elsewhere:

This is conceptually reasonable, but likely years away. We ship no native code right now. Although there are many Phabricator applications which could take advantage of an optional OS client (for example, to make it easier to upload screenshots or access files) the pathway from where we are now to building one is a very long one, and none of these use cases are near the top of our priority list.

Please read Contributing Bug Reports carefully and make sure you provide all the required information, particularly reproduction steps (see Providing Reproduction Steps). Thanks!

Sure, let me split the subproject/workboard piece out and we can walk through it. (I may not get to this tonight because I have had a long day of Business Things.)

On the "public preview" use case I do think "--plan-changes + [DRAFT] in title + just let Herald triggers fire, if users configured them they can deal with knowing about your not-quite-perfect-yet changes" is fairly reasonable, which is part of why I've resisted pursuing this until now.

to avoid accidentally forgetting to pass an additional option in cases where you did intend it

Another possibility is:

We've never seen any real interest from other installs in a default preview-before-publish mode, and I'm not aware of any class of mistakes that users routinely make or wish to correct which this mode would aid in (if I was, we'd try to detect/fix them in arc diff so users didn't need to go to the browser). We've also never seen other interest in the annotate-before-publish use case. T949 is the only task in this vein that I was able to dig up, and focused on previewing the diff only. I'm not really sure what problems this mode solves outside easing adoption when coming from another tool which works like this.

As a sanity check here before I actually build it, is anyone who is interested in configuring global default settings interested in configuring any settings other than mail-related settings? Or is this just T9161 in an alternate form, practically speaking?

Competing translations are waste of resources and choice is not good for users.

I do not know what are you main concerns [with direct commit access].

I'm not sure how to describe it differently.

Commit objects are not GC'ed in Phabricator?

Deleting the branch first won't have any effect, since the commit still exists.

My general line of thinking is that providing a better idea of a "context" to arc unit (e.g., diff vs build) and letting it make a default decision about which tests to run (possibly including no tests) is probably the most promising way forward here. You could still override this context with some kind of arc diff --run-some-extra-tests flag. I'm not sure if hard-coding a small number of contexts or making them fully user-configurable or something in between is the best way forward. This is probably a longer-term thing.

We have a somewhat-legitimate technical reason for this behavior: when we compute which-packages-own(list-of-paths), we do so by splitting the paths into components and then querying for the components. a/b/ is the best database representation for this.

This was a legitimate upstream bug and I was able to reproduce it by following your steps, thanks for the report. D15971 should resolve it.

If developers generally don't run tests locally, is having arc unit do anything really valuable in your environment? That is, if you solved this by de-configuring arc so that arc unit did nothing, what would you lose?

Is this the same as T6522? I'm not sure where the last screenshot came from, I wouldn't expect an FF-merge + push to trigger another evaluation of Herald rules.

Great, glad things are working. Let us know if you run into anything else.

This appears to be stable and working properly, at least for the most part.

Does your configuration satisfy the conditions described in the documentation?

This service has no relationship to Apple Computer Wiki, and can not help resolve your problem.

This is because that credential is in a restricted Space so this is ultimately the same as T9771, I'm just going to merge it there. The actual Query looks to be implemented fine so I think this is purely a Space issue.

Thanks!

I think the largest source of concern here is the (1b) and (3) rules: we aren't willing to exclude translations from other sources, and we aren't willing to give anyone direct commit access to the upstream. But Phabricator supports loading translations from external libraries, so we don't actually need to resolve these issues.

I think I have a pretty good guess about this one.

@joshuaspence, see T11010, I think. Not sure why nginx was 502'ing there, but should be fixed in HEAD.

Before I dig into this, is there any possibility this was a daemon running old code? I don't remember if I tested this explicitly and it could quite reasonably be an upstream bug, but the code at least attempts to check for this, and D15939 theoretically fixed issues with this.

We can also use weird implicit magic to try to resolve this. Here's a ruleset that will make everyone equally confused and unhappy:

I think that that creates some tension that I'm not immediately sure how to resolve:

We aren't really sold on this as a specific use case, but can give you a modern dashboard.panel.edit which will let you implement it. If there are weird followups arising from this (like difficulty managing the 300,000 transactions on the panel detail a year from now) we may be somewhat less sympathetic to them than we would be to a more on-label use case.

This is about two hours of work.

There were ultimately two sort of related requests here, although some of the discussion happened off-thread. Let's call them arc diff --draft and arc diff --try:

unfortumately

The time zone selected below has been auto-detected based on your browser settings

Yeah, current behavior is garbage. Not sure if I changed it by accident while doing other changes or we just didn't run into it before, but there's no technical or product reason for it to work like it currently does.

I suspect it isn't going to get very far because we lose our ability to optimize lookups (I wrote this in the general case as "regexp", but mean "regexp/wildcard" -- wildcards aren't as complex but I think the general case still holds).

Try /wsl_root/src/ansible/ (with a trailing slash)?

Did you fully restart everything (see Restarting Phabricator) after upgrading? I can't reproduce this and it looks like the kind of thing that could happen if Phabricator was not fully restarted.

We now send HTML mail by default.

These changes are live on this install:

These changes are now live on this install.

I made some headway on this but I'm feeling really icky about it and I think I may want to try making PHUIRemarkupView more powerful and moving away from PhabricatorMarkupInterface first.

Fair enough. I don't plan to pursue this, as written. We've seen very little interest in this, and it's not clear to me that it's the best solution to any problem.

D15962 attempts to guess the user's timezone by using the Intl API. This appears to be very accurate in Chrome on OSX, but useless in Safari/Firefox.

I'm going to close this as resolved, since I think we've substantially addressed all of the followups or there are now more narrow tasks with more focused problem descriptions available. In particular, from above:

I'm going to close this since I don't think there's anything we plan to act on here.