On Thu, May 1, 2008 at 2:38 PM, Finn Arne Gangstad <finnag@xxxxxxx> wrote: > Today, submodules seem to be a "read-only" implementation of the > supermodule. By that I mean that it is (only?) suited for creating a > supermodule that consists of independently released submodules, where > all development happens in the submodules, and you sometimes update > the supermodule to refer to a new version of a submodule. > > What I've tried to achieve with submodules is a bit different: I want > most development to happen in the supermodule _as if_ the submodules > were part of the supermodule. There are two reasons for not doing it > with one big module: Total size can be a bit too big, but most > importantly, some submodules are shared between different super > modules and there is a certain level of synchronizing. Does this match > your scenarios in any way? Your version (the second paragraph) matches my usage exactly. The first paragraph does not, but I gather from some discussion on this list that it does match some people's use cases, so I guess it should continue to be available. > o Branching "crawler" means branching "os-lib" > o You can send a patch that contains changes both to "crawler" and "os-lib" > and get it applied in a resonable way as ONE modification (and git-am > would do the right thing) > o Merging branch a and branch b in "crawler" also merges the matching > branches a and b in "os-lib". > o Pushing the supermodule also pushes the submodules The above would fit fine into my workflow, although it might be more fancy than I really need. Personally, I don't mind thinking of my submodules as separate projects (ie. I should expect to commit, branch, merge, and push separately). But if the above features existed I would adjust my working style to use them, just for the added day-to-day convenience factor. Doing things like a single patch against one repo is a bit messy, because (presumably) you'd have the same commit message in both repos, which wouldn't really make sense. > - Enable new behaviour with "git subdirectory" instead of "git submodule", > and let "git submodule" keep the old behaviour. If we get to the point where patchsets are gettingd sent around to play with this, is it better to modify git-submodule or to create an entirely new file? I don't know the preferred way of doing this. Have fun, Avery -- 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
