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
- targeting the current working copy state, or some descendant of it; and
- have uncommitted, unreviewed changes; and
- intend to publish those changes.
Suppose you are on branch
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.