Re: Making submodules easier to work with (auto-update on checkout or merge, stash & restore submodules)
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:
Show 53 quoted lines
> 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
Tim Harper <timcharper@gmail.com>