Andreas Ericsson wrote:
> Indeed. With the "tight" integration option we'd also have to have the
> mechanism to rewrite the tree-entries with the location where the
> submodule is located in the working tree. This might be needed anyways,
> but it sure as hell seems a lot easier to just tack that part on when
> doing a checkout and actually creating all the files.
Excellent idea! This way most of the concerns for "separate repositories for
submodules" layout about ability to rename directory the submodule resides
in, or move submodule are resolved. The other part would be to use
submodule-aware git-mv to move submodule(s).
Perhaps the following solution would work best:
* refs/submodules/<module> holds sha1 of top commit in submodule
* objects/info/submodules is a file which can be automatically generated
(or at least automatically updated) on checkout, with the following
contents:
<module> TAB or SPC <path to submodule, or GIT_DIR of submodule, or
GIT_OBJECT_DIRECTORY of submodule>
with the usual rule that # and ; means comment, \ at end of line is used
for continuations, empty lines doesn't matter etc.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html