Re: [RFC] Submodules in GIT
- From
- Torgil Svensson <torgil.svensson@gmail.com>
- Date
- Dec 16, 2006, 01:13 UTC
- Message-ID
- <e7bda7770612151713k418434e6gd8d565e49a766477@mail.gmail.com>
- In-Reply-To
- <e7bda7770612151543o39c9d233q91ea643a134196d3@mail.gmail.com>
On 12/16/06, Torgil Svensson <torgil.svensson@gmail.com> wrote:
Show 20 quoted lines
> I'm very open to suggestions here, but the concept growing in my head > is based around Linus 'module'-file and keep things simple. A git > configuration file that specifies: > * link name for reference > * local path to link > * submodule source > * submodule path to tree/blob > * submodule commit / HEAD / branch > * options (depth-limit , ...) > > I'm reconsidering having the path-name in the link, it should be > sufficient to have two SHA1's, one for the commit and one for the > tree/blob. Super-module should have the tree/blob in it's database so > that the link part only is there for version information and reference > (checking dirty state or history on the submodule). This way it easy > to clone the super-project and use it without having to map up all > sub-project sources. Sub-project sources is not important for version > information and could always be specified in the project in a > README-type of file. >
See it as the link only is there for the version handling between different modules and it's the module file that give an UI to the the link (which project, branch, ....). Many users will not care whats behind those links, but if they want to edit the link they have to create the modules file or fetch it somewhere - it may even be provided and version controlled in the project itself.
example tree object:
100644 blob <sha1 of blob> README 100644 blob <sha1 of blob> REPORTING-BUGS 100644 link <sha1 of blob> <sha1 of commit> 040000 tree <sha1 of tree> arch 040000 tree <sha1 of tree> block 040000 link <sha1 of tree> <sha1 of commit>
Note that the links functions exactly as the blobs and trees in the database. The difference is that they origin from _a_subproject_ (we don't care which in this stage) with the specified commit SHA1. If the link isn't represented in the modules file, it's no big deal, it can be added later on if needed.
If the blame-game begins or if we want to check what we're using on a submodule level we can always pinpoint the exact file/tree content and