Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > But the more fundamental question is: should we eventually have a mode in > cherry-pick (or for that matter, apply!) which can change the submodule? > And if so, how to go about it? I think that would be handled in exactly the same way as switching between two branches that bind different commits at the submodule path. Your work tree and index knows commit X is at the path, an operation wants to have commit Y at the path as its result. What's next? It does not make much difference what that "an operation" is. It can be apply, cherry-pick, revert, merge, or branch switching. I think they can and should follow the same rules. The most important rule is not to lose local changes, be they in the index or in the work tree. So "an operation" would error out if the index does not match HEAD at such a path, and the work tree does not match the index. The implementation of "work tree does not match the index" is different when you are talking about a regular blob vs a submodule. For a blob you know what we do. For a submodule, I would imagine that we would check if both the index matches the HEAD and the work tree matches the index in the submodule (this would go recursively). And after making sure we won't lose local changes, we switch the submodule directory from commit X to commit Y. Most likely detaching the HEAD with "cd sub && git checkout Y^0" or something like that. Then probably there will be an option added to loosen that "work tree matches the index" check and uses "-m" option to the checkout in the submodule directory. More tricky is what to do with a submodule that would disappear, though. For that, we would want .git/subprojects/foo.git/ trick we have discussed in the past or something similar. - 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
