Re: Making submodules easier to work with

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 1, 2008, 19:55 UTC
Message-ID: <32541b130805011255t4b37a73cx9d670b9250e787c6@mail.gmail.com>
In-Reply-To: <20080501183837.GA4772@pvv.org>

On Thu, May 1, 2008 at 2:38 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:

Show 13 quoted lines

>  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.

Show 7 quoted lines

>  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