Andy Parkins wrote:
On Wednesday 2006, November 29 16:03, Martin Waitz wrote:
>> - when updating the supermodule, you have to take care that your
submodules are on the right branch.
You might for example have some testing-throwawy branch in one
submodule and don't want to merge it with other changes yet.
What is the "right" branch though? As I said above, if you're tracking one
branch in the submodule then you've effectively locked that submodule to that
branch for all supermodule uses. Or you've made yourself a big rod to beat
yourself with everytime you want to do some development on an "off" branch on
the submodule.
Perhaps I'm just daft, but I fail to see how you can safely track a
topic-branch that might get rewinded or rebased in the submodule without
crippling the supermodule. Wasn't the intention that the supermodule has
a new tree object (called "submodule") that points to a commit in the
submodule from where it gets its tree and stuff? Is the intention that
the supermodule pulls all of the submodules history into its own ODB? If
so, what's the difference between just having one large repository. If
not, how can you make it not break in case the commit it references in
the submodule is pruned away?
One possible way would ofcourse be to add something like this to the
supermodule commit:
submodule directory/commit-sha1
tree submodule-tree-sha1
but then you're in trouble because the supermodule will have the same
files as all the submodules stored in its own tree. I'm confused. Could
someone shed some light on how this sub-/super-module connection is
supposed to work in the supermodule's commit objects?
--
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