Martin Waitz <tali@xxxxxxxxxxxxxx> writes: > But we can also leave those details for later when we are clear about > the complete semantics. At the moment it is important to reach a > common base everybody agrees on and which is enough to experiment with > all the high level tools. Overall I am reasonably happy with the direction these "smaller" patches take us, although I suspect the semantics implemented by this series _might_ need to be scrapped when we start talking about switching between branches that has and does not have a subproject at that path, and other corner cases we do not forsee right now. I think we are Ok, as long as we make it is clear that we currently do not support switching from a commit that has a submodule at one path to another commit that does not (in which case with a naive implementation we would end up having to nuke the submodule, and we need to have a way to save it, which we discussed yesterday, with .git/subproject/$name.git/ being the stashed away mirror to either quick-clone from, or symlink to). And more importantly, we would need to make it crystal clear that the superproject support by the Porcelain layer is still experimental and is subject to change in potentially backward incompatible way. We haven't had enough experience to decide the best semantics from day one, and experience cannot be gained without playing with something small like this series anyway. We may come up with a much superior design after gaining the experience, and if that is incompatible with the layout this series assumes, so be it. We'd have a big feature release that changes the semantics and that will incur some transition pain, but overall we would be better off with the final result. A clear separation of the superproject and the projects it uses as its submodules helps us here. At the worst case, migrating to the updated layout in the future would involve moving .git directories around in the checked out tree and perhaps making symlinks and/or setting up various .git/config files by hand to imitate what the final toolset would have done for the user, which should be manageable. - 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
