On 4/30/08, Tim Harper <timcharper@xxxxxxxxx> wrote: > > The problem, of course, is that you can easily have valuable, but > > not-tracked, files in there. Deleting the submodule is therefore no > > option. > > Submodules are not deleted. They are moved out of the working copy into a > folder in .git. Therefore, upon changing back to the branch with the > submodule, they are restored, without nay a hair on their head lost. <drool> Yes! I'm a little sad that I didn't think of that, because it sounds like *exactly* what I want. What about the following case: - submodule matches the super module checkin - make changes to submodule but to *not* commit them - switch supermodule branches, which should checkout a different submodule - submodule checkout causes a conflict with uncommitted files What will/should happen here? It seems like either the supermodule's submodule pointer won't be set properly (ie. git-submodule-update will fail, but the supermodule won't be marked as conflicted, thus git-commit in the supermodule will commit the wrong submodule revision) or else submodule files might have to be lost or something. Also, someone earlier asked for a link to your work. I'd like to see it too, as I don't know what a "textmate git bundle" is. I gather textmate is a MacOS X program, but I don't know what that has to do with git-submodule :) Thanks, Avery -- 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
