Re: Making submodules easier to work with

["Avery Pennarun" <apenwarr@gmail.com>]

On Thu, May 1, 2008 at 2:38 PM, Finn Arne Gangstad <finnag@pvv.org> 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