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...)
This commit is contained in:
parent
638d7fb6ab
commit
0f68c8e315
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue