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

[Andreas Ericsson <ae@op5.se>]

Tim Harper wrote:
> OVERVIEW:
> On the Git TextMate Bundle, I've automated a lot of the submodule 
> commands to make them not a terrible pain to work with. (don't get me 
> wrong - I really like the git submodule implementation, I just don't 
> like how hard it is to work with).
> 
> "WARTS" WITH EXISTING IMPLEMENTATION
> 1) The submodule stays in the working copy when changing to a branch 
> that does not have a submodule.  This can break a build and cause 
> problems.  To work around, I have to delete the folder completely 
> (git-clean).  Then, when I switch back to the branch again, I have to 
> re-download the submodule.
> 2) I have to type "git checkout branch && git submodule init && git 
> submodule update" to be sure that I really have the whole contents of 
> the branch.  That's 3 commands, and a lot of typing.
> 3) If I don't run "git submodule update", and carelessly run "git commit 
> -a" or "git add .", I risk propagating a submodule version from another 
> branch or undoing an important change.
> 
> SUGGESTED ALGORITHM (AS HAS BEEN IMPLEMENTED IN THE GIT TEXTMATE BUNDLE)
> When pulling / merging / changing branches:
> 1) cache all submodules to ~/.git/submodules_cache
>    a) move from the working directory to a folder that is a MD5 hex-hash 
> of both the submodule path and the submodule url
> 2) execute the pull / merge / branch change
> 3) restore all defined submodules to ~/.git/submodules_cache (only the 
> submodules that are still defined after the merge / change / pull)
> 4) execute git submodule init && git submodule update
> 
> 
> PITFALLS:
> pitfall)
> If you commit a change on a submodule that's not on a branch, 
> auto-updating submodules will make it difficult to revive that change.
> 
> workaround)
> Don't allow the user to commit unless they are on a branch.
> 
> ... couldn't think of anymore.  Anyone?
> 
> CONCLUSION
> So far, this algorithm holds up well in my use cases, and has made 
> submodule management seamless for me (I don't have to know that I'm 
> working with submodules).  It's resolved every one of the above outlined 
> interface warts.
> 
> Would it be a good idea to build this algorithm into git?  What would be 
> the best approach?  Am I completely overlooking something by designing 
> the Git TextMate bundle to handle submodules this way?
> 

I don't use submodules at the moment, but I have several "lib-ish" pieces
of code that would benefit greatly from becoming submodules. The not-exactly
seamlessness of them has so far been a hindrance though, but it sounds as
if your changes (assuming they don't affect anything else) should make lessen
the submodule headaches somewhat.

So, where be the patches?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231