Re: Notes on Using Git with Subprojects

From: Junio C Hamano <junkio@cox.net>
Date: Sep 27, 2006, 21:05 UTC
Message-ID: <7vhcyt81gn.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060927124413.GN1221MdfPADPa@greensroom.kotnet.org>

Sven Verdoolaege <skimo@kotnet.org> writes:

Show 10 quoted lines

> On Wed, Sep 27, 2006 at 02:01:11PM +0200, Johannes Schindelin wrote:
>
>> AFAICT this is not the idea of subprojects-in-git.
>
> As already pointed out by Daniel, there is no such thing as
> "the idea of subprojects-in-git".  There are many ideas of
> subprojects-in-git.
>
> I, for one, would want to commit the changed state of a subproject
> to the superproject explicitly.

I think this is a very good summary of the point in this entire thread. Different workflows call for different granularity, and if something deserves to be called "subproject", not just "a subdirectory of a single project", it is not unreasonable to think that it would want to track its own state at different pace from the other parts of the project, and at finer grain than the project taken as the whole.

Not allowing subprojects to do so means every little change anywhere in the project tree results in a tree-wide new commit object; in that case, the whole thing is a single large project from core-git's point of view.

Avoiding checking out parts of the project tree that you do not care about while you work on such a single large project is another interesting and useful area to think about, but I would say at that point it is not about subproject at all -- it is about working in a sparsely populated working tree of a single project.

XCB team recently told us that they started from such a single large project and now they are splitting that into separate pieces. Their experiences may be valuable to be shared to discuss pros-and-cons of these two approaches.