Jens Lehmann <jens.lehm...@web.de> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html