Jens Lehmann <Jens.Lehmann@xxxxxx> writes: >> I think this is closely related to Martin's list of wishes we >> earlier saw in the thread: remind the user to push necessary >> submodule tip before the top-level commit that needs that commit in >> the submodule is pushed out. Giving projects a way to implement >> such a policy decision would be good, and having a default policy, >> if we can find one that would be reasonable for any submodule users, >> would be even better. Would adding a generic pre-push hook at the >> top-level sufficient for that kind of thing, I have to wonder. > > That could call "git push --dry-run --recurse-submodules=check" to > deny the push if the submodule commit isn't on a remote branch. > that would only work for a single hardcoded remote, as the remote > itself does not seem to be passed to the pre-push hook. > > So me thinks adding a configuration option for the --recurse-submodule > option of push is the best way to achieve that. This could be set to > "check" ... Yes, that uses only a single hard-coded decision, and making the branch name or remote name customizable is not enough, as you are still hardcoding "if ... isn't on" part. It is not far-fetched to imagine a project wants to add more restrictions to what commit in the submodule history can be bound to a tree of a published commit in the top-level project (e.g. "must be a tagged release point", "must be older at least by more than two weeks", "must be signed by one of these developers' keys", etc.). So I am not yet convinced that a simple "option" that supplies a few parameters to a single hard-coded policy is sufficient in the long run. -- 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