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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 11, 2013, 23:16 UTC
Message-ID: <xmqqa9g7t1vb.fsf@gitster.dls.corp.google.com>
In-Reply-To: <52A8E124.4000002@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 17 quoted lines

>> 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.