git.md: Expanded a note to try to stress what you need to do if you're playing

games with submodules.

(I overlooked this when cherry-picking an LLVM commit today, and wasted some
time wondering why I wasn't seeing any effect in my resulting `rustc` build...)

1 files changed, 7 insertions, 2 deletions

diff --git a/src/doc/rustc-dev-guide/src/git.md b/src/doc/rustc-dev-guide/src/git.md
index e9588fd5977..6af774ca803 100644
--- a/src/doc/rustc-dev-guide/src/git.md
+++ b/src/doc/rustc-dev-guide/src/git.md
@@ -415,8 +415,13 @@ This is because, like any dependency, we want to be able to control which versio
 Submodules allow us to do just that: every submodule is "pinned" to a certain
 commit, which doesn't change unless modified manually. If you use `git checkout <commit>`
 in the `miri` directory and go back to the `rust` directory, you can stage this
-change like any other. This is usually done by the maintainers of the
-project, and looks like [this][miri-update].
+change like any other, e.g. by running `git add src/tools/miri`. (Note that if
+you *don't* stage the change to commit, then you run the risk that running
+`x.py` will just undo your change by switching back to the previous commit when
+it automatically "updates" the submodules.)
+
+This version selection is usually done by the maintainers of the project, and
+looks like [this][miri-update].
 
 Git submodules take some time to get used to, so don't worry if it isn't perfectly
 clear yet. You will rarely have to use them directly and, again, you don't need