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

[Tim Harper <timcharper@gmail.com>]

clarification:

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 the submodule to .git/submodules_cache/`echo  
"$submodule_path\n$submodule_url" | md5`
2) execute the pull / merge / branch change
3) restore all defined submodules from .git/submodules_cache to their  
respective working directory locations (only the submodules that are  
still defined after the merge / change / pull)
4) execute git "submodule init && git submodule update"


On Apr 29, 2008, at 10:08 PM, 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?
>
> Thanks,
> Tim