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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 10.12.2013 00:56, schrieb Junio C Hamano:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
> 
>> On Fri, Dec 06, 2013 at 02:40:15PM -0500, Martin Langhoff wrote:
>>> On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>>> Right you are, we need tutorials for the most prominent use cases.
>>>
>>> In the meantime, are there any hints? Emails on this list showing a
>>> current "smart" workflow? Blog posts? Notes on a wiki?
>>
>> None that I know of mainly because we have not yet reached the goal we
>> are aiming at. Maybe we should write something, A few points from
>> $dayjob that come to my mind:
>>
>>   * A submodule commit is only allowed to be merged into master in a
>>     superproject commit if it is merged into master (or a stable branch)
>>     in the submodule. That way you ensure that any submodules commits
>>     that are tracked in a superproject are contained in each other and
>>     can be cleanly merged. (no rewinds, one commit contains the other)
> 
> 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. But
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" for those who want to push the submodule manually and to
"on-demand" for those who would like to push automatically. And with
that option the user could configure push just like he already can do
for fetch and pull.