Try differential.querydiffs.

How would we distinguish between source/android/browse/carafe/ being "browse branch carafe of repository android" vs "browse the home page of repository carafe located at path android/browse/" in such a scheme?

This document may also be helpful in scripting Phabricator commands:

The Aug 19 2015 reply from James Day in https://bugs.mysql.com/bug.php?id=66546 gives me some hope that MySQL may adjust behavior here. Although that comment is now almost a year old, it responds to a comment from about two and a half years prior, so this may actually be fairly new in MySQL timescales.

I think this is the corresponding MySQL bug:

We can limit the number of instances, but I think the big question we want to answer is how many free instnaces convert to paying instances over some long period of time.

I think this is reasonable to pursue, but I'd like to put the capability at the ApplicationSearch level rather than making it specific to one field in Feed -- basically, provide not(user) and not-viewer() or typeahead functions (or similar functions with better names).

Cool. We can build this later for "free tier trial" if we do that, since we would definitely make different decisions based on the data then (0% conversion = don't do it, 100% conversion = ship it immediately, somewhere in the middle = run the numbers or whatever).

Oh, I can skip it if you aren't too concerned about it, it just came up and I didn't want to forget about it. I think it's like 10 minutes of work, but I'm perfectly happy to not do that work too. I don't think having this data would change any decisions I'd make, at least, even if the data showed extreme results:

I think this should be fixed in HEAD of master now. It should promote to stable pretty shortly, probably. Let us know if you're still seeing issues after updating, and thanks for the report!

I'd theoretically be open to doing that kind of thing, but I worry it would waste a lot of our time in arguing over whether or not something is really a good bug report or not. We already see a lot of this with our security bounty program and the definition of a valid report there is very narrow.

I think we already add this flag in most cases (via ArcanistGitAPI->getDiffBaseOptions()), but the specific check in arc land doesn't go through that code (since it doesn't really care about the diff, just if the are any changes at all).

Cool -- I don't think we can really detect this because we don't have an opportunity to run any code to check for it. We could possibly have the web UI run a setup check, but I think we get about 1 of these a year and it's reasonably likely that users try to run bin/* before hitting the web UI anyway. If you have any ideas about how we could have caught/prevented this, let us know.

They should be symlinks. As git represents both symlinks and the executable flag, it should be unnecessary to chmod them.

ICFP2016 starts in about 6 hours:

(Possibly it might be easier to select the correct audience in Phabricator since you can use projects or other rules, but all of the use cases here and elsewhere just want to hit everyone, I think.)

Yeah, basically like the Facebook Rooster system except making it act as "pinned notifications" instead of "pinned dashboard panels". We could do either, reasonably, although it's slightly messier to do a real-time notification of "a new panel appeared on all dashboards, go look". But I'm basically not sure why this is better than email in any case where the users are employees.

I think a global banner (or some equally omnipresent, persistent element) is reasonable for "this system is going down in a couple of minutes". But if that's the only really good use case we have for it, though, I wonder if we shouldn't just build a "shutdown in X minutes" feature that automatically does this, counts down, stops new batch jobs from starting, maybe pauses builds, puts the system into read-only when the countdown finishes, etc. -- a dedicated "graceful shutdown" feature instead of just a broadcast feature. I don't think any of these things are really problems today, but I could imagine more of a "shutdown process" being useful in the future.

Yeah, agreed. I added a little discussion to T8145.

@bjshively, for this use case:

• T11427 is similar.
• T10855 discusses a similar and possibly overlapping use case (mirroring system status into Phabricator), but I believe that use case isn't after global/on-all-pages notifications.

T8145 is also related, and maybe a little closer to intent here. I can retarget that.

T11428 puts the corporate communication wheels in motion to make this change.

Update past rPa5b26104 (Jul 9).

Closing this since we haven't seen a response for about a week, this report didn't follow the instructions by omitting version information, and it's very likely that this is resolved by updating.

Yeah, T7447 is probably the best source of discussion about this.

D16367 make the order consistent (instead of reversed) in the task list view and on workboard cards.

I think this is a perfectly reasonable capability to want in the general case, I just want to make sure that this isn't a big fancy solution to a problem that could also be solved by checking a checkbox or making a one-line change to the build or whatever. Definitely possible that most Jenkins users are just doing very basic stuff with it, though.

I'm not super familiar with Jenkins -- what makes this job require parameters in the body? Other users seem to be using Jenkins successfully without requiring this capability on the Phabricator side, as far as I know.

Ah, that one's easier.

@eadler, does your use case need a fancy content type like application/json, or just plain old www-url-normal-web-form-encoded?

I don't think this is a sort stability issue: we're preserving the order which the user who entered the tags originally used (in this particular UI it looks like we actually use reverse order, which I'd consider a bug, but other UIs like the "Tags" in the rightmost column and when editing the tags via "Edit Task" we use the original order).

Just to be completely sure I understand this:

You can use --verbatim to cause this update.

Just to clarify, workboard columns with a limit should currently show text like this in the header:

If you can identify why sudo was broken and what you did to fix it, we can probably add a setup warning to test for this problem. However, since we haven't seen other users with broken sudo and we couldn't help users resolve the issue with available information even if we did detect it, I don't think pursuing a check in the upstream is worthwhile.

(You can't write "Run Build Plans: ..." personal rules, but you can write them in object rules, which isn't too much different.)

It's also probably bad/inconsistent that you can run builds via Herald which you could not run via the web UI.

I have mixed feelings about relaxing this. I think there are basically two parts to this:

I generally expect all signing to be external, at least for the foreseeable future.

In the case of Debian 9, it looks like it won't even freeze for 6 months. If it ships with PHP 7.1, it may well run Phabricator. It is impossible for us to answer compatibility questions about hypothetical software slated for release the better part of a year from now.

In this particular mock it's slightly confusing to me that the left nav looks like it has a "Table of Contents" header but is showing a document hierarchy (i.e., element that looks like a header does not seem to be labeling the content beneath it). Not sure if that's a mock thing / interaction thing / whatever.

It would also be nice to recognize that "oldname" became "newname" so we could redirect, continue delivering mail, etc. This is a little more involved.

Oh, I think I made up point (1) above -- that's already the behavior.

I'd like to make the Diffusion UI more field-focused (T9713). which is maybe adjacent, although not directly related.

Also, please note this: