login
Search
On Friday 15 December 2006 18:43, Torgil Svensson wrote:Ah, now I understand. I somehow missed this notation. That all sounds fine, but how do you create such symlinks in practice? Do you want to introduce special porcelain commands to create them? Especially, what is the SCM user supposed to do to change the link target, ie. from <commit>/path/to/subtree to <commit>/path2/to2/subtree2 ? Should this do a re-checkout at the other point? By linking a file from a submodule, such a link seems to force that this file has to be at a fixed position in the submodule. Otherwise, some magic has to happen when the file is moved in the submodule, possibly leading to a dangling link, eg. if the whole subdirectory specified in the link is removed. IMHO this is getting way to complex. Much simpler is to include the full submodule at some path in the supermodule, and create normal symlinks from the supermodule into the submodule. If you only want to check out part of a submodule, this should be done with path-limiting checkouts, which should be a feature totally independent from submodules. And if you want to limit the number of objects transferred in cloning of a subproject, it is better to further split this subproject into multiple subprojects itself. Of course, you need the submodule fully checked out somewhere in the supermodule, and the link goes into the submodule directory. The versioning is given by the supermodule/submodule link. As already said: the link has to go into a submodule directory, which will be checked out automatically with the clone of the supermodule. The problem is not the representation in the git repository, but the checked out module/submodule, where you need to use normal UNIX file semantics. To move submodules around, the user should be able to just use the normal UNIX "mv" commands, and git should be able to detect move actions after the fact. The simple thing here is that currently, git does not have this problem as it tracks content, and does not even try to detect any moves at commit time. This is different with submodules, as there, you want to be able to track moves of any submodule root directories. This now becomes a problem if you use symlinks to "unify" multiple checkouts of the same submodule at multiple places in the supermodule, and move the symlink around, as it easily can get dangling this way. Thus, you would not have a way to see what submodule this link was talking about. And for this thing, I do not see how your link object could help. So it is better to use a simple submodule concept, and for this corner cases, we perhaps could expect the user to fix e.g. a dangling symlink to a previous submodule checkout himself, using a meaningful error message. If you have a source commit chain A => B => C => D, you want to make any build commits totally independent: you first only are interested in a build commit for source versions A and D, and later find out that a build commit for B and C would be nice, too. If you force build commits into some history order, this order now would be A => D => B => C, which makes no sense. Build commit independence can easily be achieved by making every commit parentless, without further history. You still have the link to the source version via the submodule link in the tree. But to not loose any such build commits, they have to appear as tags or refs (unless integrated in another superproject build commit). The version coupling will be there if the whole submodule is available at some path in the supermodule checkout, as said above. Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
