On Wed, Dec 11, 2013 at 03:16:24PM -0800, Junio C Hamano wrote: > 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. Well, for the implementation of --recurse-submodules=check on push we tried to be as dumb as possible and just try to find out whether the commit is on any remote. The reason is that when someone works on a branch and pushes it for demonstration/backup/before holiday the most common mistake is that he forgets to push the submodule when pushing the superproject. So "some remote" seems to be the most common denominator for push here. At least its better than no check at all. For extended rules that answer questions like: "When am I allowed to merge in master?" we need some kind of workflow definition from which we can deduct such rules. A pre-push hook would allow to define rules but how about an approach that is easier for the user and can maybe guide him to the correct workflow. I find workflow guidance is a general problem in git and even though we use hooks at $dayjob they are not always sufficient. E.g. we enforce an "all commits have to be reviewed first before they enter master" policy which is correct in most situations. But for more lightweight projects I would like to loosen this rule. The problem relies in the automatic distribution of hooks or options for them by project instead of by installation. One idea: We could distribute a default set of enabled hooks that implement several typical workflow options which can then be enabled by simply choosing one option. The configuration should be distributeable via the project e.g. a .githookconfig or .gitworkflowconfig ? The git tools could then adapt their defaults depending on such a workflow definition. But it also means we would first have to collect and define some typical workflows. What do others think? There probably have been other ideas about workflow definitions already, no? Cheers Heiko -- 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