From: Tim Harper Date: Wed, 30 Apr 2008 21:37:16 GMT Subject: Re: Making submodules easier to work with (auto-update on checkout or merge, stash & restore submodules) Message-ID: In-Reply-To: <32541b130804301331o70310831raf71db7cbb51d507@mail.gmail.com> On Apr 30, 2008, at 2:31 PM, Avery Pennarun wrote: > On 4/30/08, Tim Harper 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. > > > > Yes! I'm a little sad that I didn't think of that, because it sounds > like *exactly* what I want. > Glad to hear I'm not the only one who feels that way :) > What about the following case: > - submodule matches the super module checkin ? > > - make changes to submodule but to *not* commit them Changes will never be lost, because the submodule is either stashed away, working copy and all, or a "checkout" command is issued to change the HEAD pointer. The latter is like changing branches with uncommitted code - the changes will either be carried, and possibly conflict. > > - switch supermodule branches, which should checkout a different > submodule Submodule is automatically changed for you, so changing branches makes sure you always have the "whole project". Recursion isn't handled at the time being, so it only works for 1 level deep. > > - submodule checkout causes a conflict with uncommitted files Oooh - this could be a problem currently, especially if you're not on a branch. If you have to resolve conflicts the way to resolve them is to commit, and you can't switch to a branch to commit unless you resolve your issues. In which case, you'll probably want to resolve, commit, then create a new branch with your current HEAD, then merge it into a branch. I'll visit that as issues arise. This is bleeding edge experimentation here :) > > > 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. This is a good point: I don't believe that submodules have anyway to mark the submodule revision as "conflicted". In order for this concept to be handled in its full glory, that will most certainly need to be handled. > > > 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 :) > TextMate is an editor for MacOSX. Here's a link to the bundle. It's written in ruby.: http://github.com/timcharper/git-tmbundle/ What does it have to do with submodules? It's essentially a "GUI" for git. It provides automation for a lot of common tasks also. My team has a need for submodules, but unfortunately in their current state I couldn't recommend it to them, so I "smoothed over" the rough edges by automating a lot of the awkwardness. So far, it's been working well for us. > Thanks, > > Avery Thank you! Tim