Re: Making submodules easier to work with (auto-update on checkout or merge, stash & restore submodules)

[Tim Harper <timcharper@gmail.com>]

On Apr 30, 2008, at 2:31 PM, Avery Pennarun wrote:

> On 4/30/08, Tim Harper <timcharper@gmail.com> 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.
>
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