Do you hit these prompts frequently because your working copy is routinely full of untracked files?

I usually run some commands to do something slow and save its output for later processing.

Run a command on N machines > x

I don't delete them on a regular basis: maybe I'll need them in the future (I guess this is now called Big Data.). I purge them when I get annoyed about the clutter ("No data" as per NoSQL)

From the names it is clear that I don't want to commit them. But I panic when committing or landing because I have the impression that I'll commit/land junk.

◀ Merged tasks: T3992.

I just closed T3992 with https://secure.phabricator.com/T3992#4

I personally am using my brain fairly actively when submitting code for review or landing code, as well as keep my code pretty clean. As such, the questions are actually both perfect to me. While I closed T3992 with this mindset, I didn't know about this existence of this bug so maybe I am a minority?

This came up somewhere on GitHub too, but I can't immediately find it. An argument raised from Facebook was that changing this would confuse users who are used to the way it works, although I don't find that particularly persuasive.

I am personally not sympathetic to users who fill up their working copies with untracked, unignored files, and believe this is a really bad practice. However, it's quite common and users who like to keep random files in working copies also don't like answering prompts about them.

The defaults on these behaviors are both the same (ignore the unchanged files), so this is a bit inconsistent. Adjusting the wording to be more consistent is probably the right approach, I just roll my eyes every time we make an affordance for "working copy full of junk" use cases.

@epriestley The use case is not so much "working copy full of junk" but more often working on multiple things at once and have not yet added some (new) files to the repo.

In my mind, this is simply an inconsistency in arc workflow which can be confusing, or worse, cause unnecessary interruptions in arc diff/land workflow.

Everyone who uses this workflow defends it with the claims that it's reasonable, convenient, and they never make mistakes. However, at Facebook, on average, this class of error caused a lot of severe mistakes, including more than a million dollars in lost revenue. Based on seeing how much damage these mistakes caused, I believe this is on average a very poor workflow, and someone on your team will screw it up even if you're perfect and really never do make mistakes. One of the most vocal advocates of having untracked files around made a mistake of this class less than a week after defending it when we first added checks.

This class of errors is easily preventable, and no one has ever given me a truly compelling reason to have untracked files in the working copy at diff time.

When I worked with SVN at Facebook, I simulated local branching by having several working copies on disk. I exposed these at sandbox1.domain.com, sandbox2.domain.com, etc., and worked on independent changes in separate working directories. This took about 20 minutes to set up one afternoon and lasted for 4 years, and I don't remember ever making an add error or cross-contamination mistake afterward -- but I almost certainly would have if I didn't separate changes.

Again, I don't think there is any argument about the flaws of this approach. But the task at hand deals with consistency of UX, nothing else.

https://github.com/facebook/arcanist/pull/81

ah perfect thank you