Linus Torvalds wrote:
...
> Think of it this way: one common use for submodules is really to just
> (occasionally) track somebody elses code. The submodule should be a
> totally pristine copy from somebody else (ie it might be the "intel
driver
> for X.org" submodule, maintained within intel), and the supermodule just
> refers to it indirectly (ie the supermodule might be the "Fedora Core X
> group" which contains all the different drivers from different people).
Could you please be a little bit more specific about how you would store
the "pristine copy". There seems to be some agreement to store the
commit id of the submodule instead of a plain tree id in the
supermodules tree object, and that all objects that are reachable from
this commit are made part of the supermodule repository (either fetched
or via alternates). Do you agree?
...
> A supermodule can never "contain changes" to a submodule. A supermodule
> would always just point to the submodule, and not have any changes
> what-so-ever of its own. The submodule is self-sufficient, and always
> contains all its _own_ changes.
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?
Regards
Stephan
-
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