On Tuesday 12 June 2007, Lars Hjemli wrote: > If you're thinking about the detached HEAD: yeah, that's a problem. My > initial plan (with later modifications) was something like this: > > ... > > $ git-submodule update > git-clone --bare git://example.com/lib.git .git/submodules/lib.git > git-clone -l -s -n .git/submodules/lib.git lib1 > (cd lib1 && git-checkout $sha1) > git-clone -l -s -n .git/submodules/lib.git lib2 > (cd lib2 && git-checkout $sha2) > ... That looks fine to me. > git-submodule push: > (cd lib1 && git-push origin $branch1) > (cd lib2 && git-push origin $branch2) This could be problematic. You are only storing changes on the given branch. Ah, you wanted to avoid this problem with the symlink? Perhaps we need better support for "push all reachable objects which are not on the remote side together with any branch tip changes". Or is this somehow already available with git-push? Or ... > I thought I could avoid 'git-submodule push' by using symlinks, but > you're right. It will not work. Back to the drawing board (again...) ... we revive the "lightweight checkout" idea: share everything but index and HEAD with a given repository. Similar to "contrib/workdir/git-new-workdir" but witt support in git-core to avoid the need for symlinks. > > A workaround for problem (1) would be to create multiple checkouts of the > > same submodule if modified, e.g. in .git/submodule/$name/$sha1 . > > And the $sha1 would be the sha1 found in the index? I don't think this > would work either. If two branches in the superproject checkout the > same submodule sha1, you could possibly want to keep different changes > in the submodule depending on which branch of the superproject is > checked out. OK, does not work. > > Allowing people to work like that is nice, but it should not be forced. > > It would also be nice to allow the user to specify another place where > > submodule checkouts are to be stored, e.g. when multiple supermodules > > share the same submodule. > > True. Maybe submodule.<name>.repopath in .git/config? (If not > specified, default to .git/submodules/<name>.git) Sounds good. However, can be done later. Josef > > -- > larsh > - 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
