Am 10.04.2010 00:04, schrieb Junio C Hamano: > As a plumbing I would prefer to leave checkout-index as is; script writers > can choose to recurse if they choose to. O.k.; what about adding an option "--recurse-submodules" to activate that behavior - without having to code it every time - when wanted? > This is not limited to checkout-index, but what is the stance of this new > feature on failures from sub-checkout when there are local modifications > in the work tree? Some parts of the work tree is checked out while the > ones after the failure that sorts later in the alphabetical order will not > be checked out, resulting in an inconsistent state (I am not saying that > it is good or bad---I am trying to see what the users should expect from > this new feature)? I would like to see the same attitude that checkout has on local files: Don't overwrite anything changed (unless forced to). And an inconsistent state should never happen, the checks on the submodules should be done before the first file or submodule is checked out (But i still have to test and verify that behavior in yet to be added tests). -- 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