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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
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
