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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
