On 11-05-31 05:26 PM, Jens Lehmann wrote: > Am 31.05.2011 23:06, schrieb Marc Branchaud: >> On 11-05-31 03:30 PM, Jens Lehmann wrote: >>> Am 30.05.2011 23:51, schrieb Marc Branchaud: >>>> Patch 2 exposes an anomaly in "submodule status", which reports that a >>>> submodule is OK even though it has deleted files. "git status" inside >>>> the submodule (and in the super-repo) both identify any deleted files, but >>>> "submodule status" doesn't prefix the submodule's HEAD SHA-ID with a "+". >>> >>> That is documented behavior. "git submodule status" only cares about the >>> commit recorded in the superproject vs the HEAD in the submodule, work >>> tree modifications are never shown by it. >>> >>> But try a "git status" in the superproject, that will give you the following >>> output: >>> # modified: init (modified content) >> >> I understand. My apologies for not reading the man page closely enough. > > No problem, maybe that's just an indication that a reference to "git status" > being more capable of telling what is going on inside a submodule is missing > to the man page for "git submodule status". Yes, that'd possibly help. >> I know there's been a lot of recent work on making "git status" >> submodule-friendly, but would there be any interest in having another prefix >> for submodule status to cover this case? Maybe ! could indicate that the >> submodule's HEAD is correct, but the working directory doesn't match it exactly. > > I'd rather leave "git submodule status" as it is and incorporate this kind > of functionality into core git (for "submodule status" it already arrived there > in 1.7.0/1.7.1, so that part is finished ;-). I hope making the "git submodule" > script mostly obsolete in the long run and would want to avoid teaching it new > stuff already covered by core git. A noble goal, certainly. So here's my basic question: How can my build system be sure that a submodule contains the correct working directory? Do I need to do both "git submodule status" to check the submodule's HEAD, then also use "git status" to see if that HEAD is correctly checked out? 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)". M. -- 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