From: Torgil Svensson <torgil.svensson@gmail.com>
Date: Thu, 14 Dec 2006 21:27:26 GMT
Subject: Re: [RFC] Submodules in GIT
Message-ID: <e7bda7770612141327r11368e4dtabe8077e96545040@mail.gmail.com>
In-Reply-To: <e7bda7770612100347j78854d79x547084972ed14e99@mail.gmail.com>

On 12/10/06, Torgil Svensson <torgil.svensson@gmail.com> wrote:
> What if we use linus "module" file concept and allow the link objects
> to track subtrees? An object may look like this:
>
> commit: <SHA1>
> link: <SHA1> /path/to/remote/tree/or/blob

> Special customer release for a specific HW platform
> ---------------------------------------------------
> "Lib1/lib1.h" -> "<lib1-commit>/headers/lib1.h"
> "Lib1/lib1.so" -> "<build-environment-commit>/i386/Lib1/lib1.so"
> "App1_binary" -> "<build-environment-commit>/i386/App1/App1_binary"

This example is somewhat complex since the build for lib1.so and the
header-file might not has gone through the same commit on the lib1
subproject.  Consider this example:


lib1 - library project (source tracking)
------------------------------------------
Blob: /src/lib1.h


app1 - application project (source tracking)
-----------------------------------------
Link: /headers/lib1.h -> <lib1-commit1>/src/lib1.h


build1 - Build project (binary build tracking)
------------------------------------
Link: /src/lib1 -> <lib1-commit2>/
Link: /src/app1 -> <app1-commit>/
Blob: /i386/lib1/lib1.so
Blob: /i386/app1/app1


Release Project (file compilation tracking)
-----------------------------------
Link: /headers/lib1.h -> <lib1-commit3>/src/lib1.h
Link: /bin/lib1.so -> <build1-commit>/i386/lib1/lib1.so
Link: /bin/app1 -> <build1-commit>/i386/app1/app1


<lib1-commit1>, <lib1-commit2> and <lib1-commit3> should be the same,
dictated by the app1 project. Can we enforce this in the modules file
or should the different supermodules fix this somehow using
scripts/hooks?

How do the super-projects in this case get access to the blobs pointed
by the links - transparent or explicit in the build-process?