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

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@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
run.