On Sunday 03 December 2006 23:32, Linus Torvalds wrote: > So a particular instance of a submodule might be "aware" of the fact that > it's a submodule of a supermodule. For example, the "awareness" migth be > as simple as just a magic flag file inside it's .git/ directory. And that > awareness would be what simply disabled pruning or "repack -d" within that > particular instance. That prohibits the problem in your supermodule and your instance of the given submodule. But IMHO, using a submodule commit which could be removed by pruning in another instance of the submodule is really not the thing you ever want. If you start your own branch in a submodule, and start to rely on it in the supermodule, you _will_ want to push this to the submodule upstream. And if you find that you have to rebase in the submodule, you simply have to rewrite your branch commits in the supermodule too. Otherwise, you effectively fork the submodule project purely for your superproject. So I suppose that in practical use, pruning in submodules probably would not have any negative effect. If it has, you made something wrong. So you probably should only a submodule commit if it has "publishing quality" (unless being on a temporary supermodule branch). Ie. any "borrowers" file should be empty. Josef - 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