Am 30.05.2011 23:51, schrieb Marc Branchaud: > Ran across some submodule behavior that seems wrong to me. I don't have the > chops to fix the issues, so I thought I'd just point them out with some unit > tests. Thanks for bringing these issues to our attention this way, having a way to easily reproduce them is very much appreciated. > Patch 1 tests the case where "submodule add" fails if the path to the > submodule repo is relative (i.e. starts with "../"). This currently fails > with "remote (origin) does not have a url defined in .git/config". Maybe > there's a reason to fail? If so, a better error message would be appreciated. I stumbled across this behavior now and then too, but according to the commit it added (f31a522a2d) it is intended that adding a relative path behaves differently than using an absolute path (it resolves relative to the superproject's origin, not the filesystem, and to be able to do that the superproject's .git/config has to have an url defined for it). But you are right about the error message, it really isn't that helpful ... > 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) -- 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