sf wrote:
That is one of the points Martin Waitz and I are discussing.
If I understand you correctly you cannot make any changes to the
submodules code _in the supermodule's repository_, no bugfixes, no
extensions, no adaptions, nothing. Do you mean that?
That would be a third alternative. In my opinion the usefulness of
submodules would be unnecessarily restricted if it comes to the choice
of either using the code from upstream as is or do not use submodules at
all. What is the point of the restriction?
That depends on your definition of submodule. In my eyes, a submodule is
a separate repo that can be committed to separately (and generally also
built separately), although it's usually built into something else. I'm
imagining most submodules will contain only library code and its testing
routines.
Insofar as I've envisioned submodules, it's a separate git repo where
you simply record a certain snapshot of the sub-repo with a commit in
the super-module, like so:
$ git commit ssl-functions/*.[ch] openssl -m "Upgraded openssl with
necessary changes to core code"
(yes, I know it's horrid to use -m to commit, and I daily advocate
against it where I work, but you get the idea, I'm sure)
Isn't this how it's supposed to work? Enlighten me, and please remember
that I'm drunk atm, so make it obvious ;-)
--
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