Am 10.12.2013 00:56, schrieb Junio C Hamano:
> Heiko Voigt <hvo...@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.lehm...@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.
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