Stefan Beller <sbeller@xxxxxxxxxx> writes: > Why is it interesting for submodules but not for standard repositories? > > If I clone a repository without submodules, it is also not recorded > that I cloned with an explicit depth=1. If you fetch, you may end up with > a deeper history as git fetch doesn't do a "reshallow" to the configured > depth. Very simple. If you do not have submodule, you would always interact with the other side directly with "git fetch" or "git pull" and have total control over when you choose to pass or not to pass extra options to choose to 1. incrementally extend, 2. deepen, or 3. unshallow. The user will always explicitly tell you, and knowing how you got there would not help you, as there is no need to guess for you. The user can do the same explicit "cd dir && git fetch" update in each submodule directory and give appropriate options to choose among the three, but I have an impression that your recent work is going in the direction of making commands that are run in the superproject recurse into submodules that automatically fetches and updates the history down there, discouraging users from working on individual submodules. You lose the flexibility to explicitly choose among the three for individual submodules, and you may want to have some smart in your "run from the superproject and recurse" tools. A submodule that was initially cloned with depth=1, perhaps because the user didn't know if the module was interesting to her in the context of working on the superproject before she had her clone of the superproject hence she only wanted to see what's there, and a submodule that was not even fetched initially when the superproject was cloned and later was "submodule init"ed and fetched with depth=1, would have the same shallow boundary, but the intent of the user would clearly be different in the larger picture. I imagined that your "run in top-level and recurse to fetch in submodules" tools would benefit if it has more information to intuit what the end user meant. -- 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