Arc land untracked versus uncommitted confusion

Prior to the 2020 Week 26 changes to arc land (see https://secure.phabricator.com/T13547), untracked files in the current directory were treated separately from un-committed changes to tracked files. Now, it appears that they have been merged and a single prompt to “Stash these changes and continue?” is presented.

This is confusing to my users (and me!) because untracked files are, outside of Menlo Park, not something that people deeply care about, but uncommitted changes are. Beyond that, when all that’s present are untracked files, no “stash” operation occurs; this use of very-specific git terminology is a bit confusing.

Beyond that, when all that’s present are untracked files, no “stash” operation occurs

Are you reporting “arc does not stash”, or “arc does something to ignore the untracked change, but it can’t be ‘git stash’, because that is not the behavior of ‘git stash’?”

I think I can’t reproduce either one. Here’s my working copy state:

$ git status
On branch publish1
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	untracked-file.txt

nothing added to commit but untracked files present (use "git add" to track)

Here’s the prompt I get, with only untracked files:

epriestley@orbital ~/dev/phabricator $ arc land --trace --hold
...

 <!> UNCOMMITTED CHANGES 
You have uncommitted changes in this working copy.

    Working Copy: /Users/epriestley/dev/core/lib/phabricator//

Untracked changes in working copy:

    untracked-file.txt

  ?   To configure Git to ignore certain files in this working copy,
      add the file paths to ".git/info/exclude".

 >>>  Stash these changes and continue? [y/N/?] y

Here’s the next line of output, where arc literally runs git stash:

>>> [18] (+39,196) <exec> $ git stash push --include-untracked --

I guess I’m really reporting “all of my users have untracked files in hundreds of repositories and want them to be ignored as they were if you typed ‘y’ in 2020 Week 25 instead of having git touch them in any shape or form”

They can do that by answering “y*” to the prompt once, but presumably they also regularly run arc land in a working copy with uncommitted changes to tracked files, and would also like arc to warn them about that?

Yeah, I think so. Is there any magic set of arc settings that will restore something that looks like the old behavior?

No. I’ve intentionally merged these prompts (and some other behavior) to simplify arc.

Well, if you ever re-examine it, it’s been my observation that most git users have lots of untracked files and thus that untracked files are a “normal” case, whereas modified-but-uncommitted files are an exceptional case, and treating them as the same is confusing.

I currently believe I’m very unlikely to re-examine this.

Separating these warnings only improves the outcome if you run arc land against the current working copy state (or some descendant of that state) with uncommitted, unreviewed changes which you intend to publish.

I think this requires a fairly high level of carelessness, and if an engineer is doing this regularly, I suspect they would likely benefit from changing their workflow so they are more aware and mindful of working copy state. A good first step would be sweeping up a little so that git status is actually useful.

Sorry, I guess I was unclear.

I want users to be able to safely ignore having untracked changes but still get a warning when they have uncommitted-but-tracked changes. I agree that if a user regularly has the later, something is definitely problematic, but right now there’s no way to ignore untracked changes (which, again, are overwhelmingly common for actual development of most applications that tend to generate a lot of intermediate garbage and logs and ephemeral files that may not be reliably gitignored) without also ignoring uncommitted tracked changes.

In modern arc, it’s safe to ignore uncommitted, tracked changes unless you intend to publish them.

There is only a behavioral difference between ignoring and not ignoring the changes if you run arc land:

  1. targeting the current working copy state, or some descendant of it; and
  2. have uncommitted, unreviewed changes; and
  3. intend to publish those changes.

Suppose you are on branch mobileui3.

For requirement (1), if you run arc land backend1 (a branch which is not a descendant of the current working copy state): your dirty working copy will be stashed, the changes currently in backend1 will land as they are, then your old state on mobileui3 (including your uncommitted changes) will be restored. This seems obviously correct, and the prompt seems unnecessary.

For requirement (2), if you instead run arc land (implicitly landing the current working copy state), or arc land mobileui3 (explicitly landing the current working copy state), or arc land mobileui4 (explicitly landing a descendant of the current working copy state) instead, but have no uncommitted changes, obviously the prompt doesn’t matter (there’s nothing to prompt you about).

For requirement (3), if you have uncommitted, unreviewed changes but do not intend to publish them (e.g., maybe you were testing some unrelated thing locally and just forgot to clean up your working copy), the committed state of mobileui3 is what will land, which is correct (you did not intend to publish the uncommitted changes, and they were not published). Your uncommitted changes will be restored afterward, which seems correct.

Having a separate prompt only matters if you satisfy all three requirements, and I believe users should very rarely be running arc land in a way that satisfies all three requirements.

Again, the specific issue here is that my users are now being prompted to stash untracked changes very frequently. They can say “y!” to make the prompt go away, but then they will not be prompted if they have un-committed tracked changes, which is a more exceptional situation that warrants prompting.

Why does it warrant prompting?