The git diff on each file costs about 10ms for me, maybe it's much slower in your (presumably larger) repository?

Above, it took me ~4m to upload 8,000 files, which is about 33 files per second. That could probably be faster, but seems reasonable to me?

The specific case of an auto-generated update from a huge commit we could probably improve, I don't think we benefit from auto-updating the revision to show the 100M-commit change and could reasonably just say "this is huge, go look at it in Diffusion instead".

Differential does not have any mode where it actually hides files, because this behavior does not make any sense to me:

Differential already does that. See D14976, above:

Sure, I agree with all that. But what do you want arc diff to actually do, technically speaking, in that situation?

What's your ideal behavior when a user changes Copyright 2015 to Copyright 2016 in 1 million files, adds a 5GB access.log file, adds the MySQL 5.1 source, all in one diff, and then runs arc diff?

Broadly, I think there are three classes of use case here:

Let me clarify: do you think a human should open a web page which has 8,000 rows on it showing that 8,000 files moved in order to review "move src/ to notsrc/", or that it's sufficient for them to review the metadata ("I'm going to move src/ to notsrc/") without reviewing the actual details of the change, as described in the "Large Changes" document?

For example, if the root cause here is just that users are super lazy (or, in the future, use cases emerge where commit access is controlled through "Land Revision" in the web UI) maybe we could provide an arc diff --no-human-review mode which pushes the changes to staging but does not attempt to display them, and tells users how to fetch and review them locally instead. Then you could arc diff your "move src/ to notsrc/", "check in a 5GB logfile", "commit the entire MySQL 5.3 source", etc., diffs and go through the motions of review without us actually needing to do any work, which is all wasted anyway since no one is going to look at the individual changes to the 8,000 files you moved.

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

For reference, this repository name input:

I think it's correct that we're very conservative about destroying data. It would be incredibly bad to remove something important because a user set repository.default-local-path to something silly like /home/important_files/ and we decided to destroy /home/important_files/CRITICAL/ because it wasn't a repository.

I can't reproduce this, nor do we have reports from other users. See Contributing Bug Reports.

Is there a (more robust) mapping mail notification → transaction(s) that I missed?

This is not a valid bug report. See Support Resources and Contributing Bug Reports.

See also "Sticky Accept" here:

The upstream discussion of this issue starts with "Chain of Custody" here: T182#133871

I'd be fine with exposing this information from some bin/auth help me with computer since anyone with CLI access has other means available to read email addresses, but we don't currently have such a command and I don't think there are any adjacent requests to motivate building one.

This is straightforward, but I'm hesitant about it because users can use email addresses to log in, and we do not currently expose email addresses to administrators. Adding this information to the activity log could reveal lots of near-misses of email addresses. While providing this information would help administrators with users who are extremely creative in their use of computers, it seems slightly worse for the bulk of normal users from a privacy/security point of view.

I actually think failing universally like that is probably fine (you can --skip-staging anyway, as long as the error tells you about it) but the UI behavior in Phabricator itself is frequently nonsensical (we basically guess that the staging area probably exists and proceed blindly).

Outside of Harbormaster, "Land Revision" is also impacted.

Specifically, the UI currently has this mess of a problem corner:

I'm just going to close this out, since I'm not sure we really need it -- D14963, D14962, and other work adjacent to T2450 found some general performance improvements in rendering. It's possible we might pursue this (and/or a highlighting cache) in the future, but I think we're fast enough now that the huge amount of upfront work the daemons would have to do to populate these caches probably doesn't make a ton of sense.

This is more than a year old now and we haven't seen other requests for it. Diffusion copy/pastes and links cleanly and I think this is sufficient in all reasonable cases I'm aware of.

Sorry, I still don't understand your root problem.

I'm going to merge this into T9622, but -- oh, @chad already got it.

Flags currently has this unwieldy dropdown, which will only get worse over time as more applications and object types are added. It would be better to use a typeahead, like the one in global search:

I removed this because the implementation was pretty hacky (saved the rule as a text string, wasn't translatable).

@chad, not sure if you have design thoughts here, but I think this is broadly reasonable.

I think it's too hard for us to guess user intent here. There's nothing a user can do which strongly signals that their flag is obsolete, since flags mean a lot of different things (in your use case, it sounds like there's no single action you take which clears the flag, just "the next action after you added the flag"). Other users (myself included) use flags for different reasons, including as long-term bookmarks. Guessing intent is also difficult because you can flag many kinds of objects, not just tasks, and we'd strongly prefer features which can be implemented globally.

Overall, the problems I currently see with watch/subscribe are:

For the sake of completeness, the root issue you described elsewhere (unsubscribes cascading into more unsubscribes) is fixed (at least, indirectly) at HEAD, after 536d3a2, which stops self-subscribes and self-unsubscribes from publishing feed stories, mail, and notifications.

I don't currently plan to remove the option

Oh, by "remove the option" I meant "remove the option to subscribe to a project if you are not a member of the project" -- that is, "Subscribe" is disabled if you aren't a project member. I don't currently plan to remove the option, although I am leaning towards making members not be subscribed by default.

This isn't the same as T6183 or T6113, and isn't expected.