Re: Publishing "filtered branch repositories" - workflow / recommendations?

Jens Lehmann [off-list ref] writes:

quoted

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.