Re: [PATCH 07/16] git-read-tree: take --submodules option

From: Junio C Hamano <junkio@cox.net>
Date: May 20, 2007, 18:33 UTC
Message-ID: <7vbqgfmjki.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070520155407.GC27087@efreet.light.src>

Jan Hudec <bulb@ucw.cz> writes:

Show 5 quoted lines

> IMHO it makes more sense to fetch during fetch of superproject:
>
>  - If you don't fetch the superproject, it won't start refering to
>    unavailable commit of subproject. So should only need to fetch subproject
>    after fetching superproject.

Eh, I was suggesting that the subproject fetch would come after checkout in "fetch and then checkout" sequence of the superproject, and if you are arguing against it, you should justify why it should not happen before checkout, as we both agree it should come after fetch of superproject. Your argument is like saying you have to git-init before doing anything so you should fetch when you git-init. That's not a justification.

>  - If you fetch from more than one location, you want to fetch subproject
>    from location corresponding to where you fetch superproject from.

Not at all. There is no reason to believe that the case that superproject and subproject come from related URLs is more common. One of the reasons to do a separated project organization is to allow looser bindings of the project from project administrative viewpoint. The integrator may not necessarily have any control over what the subproject guys do, and more importantly, the subproject people do not even care nor be aware of the fact that their project is sometimes bound inside other peoples' superprojects. Think of the embedded appliance vendor binding the kernel, libc and busybox in their superproject that holds them together with the build infrastructure. The kernel folks certainly do not particularly care about the vendor.