Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > Note that my automated builds don't really care about possibly-modified files > or anything like that. They just want the exact tree that corresponds to the > commit ID recorded in the superproject. (Previous builds might've left some > cruft lying around, and the automated build wants to be sure that's eliminated.) > > Maybe I should just forego the status-checking altogether, and do "git > submodule update path/to/sub && (cd path/to/sub; git reset --hard HEAD; git > clean -dx)". It really depends on what you really care about. If the working tree is shared between your build-bot and a human user, the build-bot may want to make sure it does not overwrite and lose work by a human, but otherwise, instead of checking if something is stale (and having to design what to do when it actually finds something is stale), actively causing the state it wants to see appear in the working tree sounds like a simpler, more robust and much saner thing to do. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html