Re: Making submodules easier to work with

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

On 5/6/08, Roman Shaposhnik <rvs@sun.com> wrote:
> May be my brain is saturated with "partial cloning" but somehow the
>  following looks like an interesting twist on a decentralized SCM:
>  imagine that the picture given by Finn Arne Gangstad weren't
>  static. IOW, os-lib wasn't really a separate component to begin
>  with but was first developed as part of a "crawler" and only
>  when the other team started to implement "indexer" there was
>  a need for os-lib to be shared between two independent projects.
>  Is there any nice way to express such a dynamic history sharing,
>  short of truly refactoring os-lib into a separate Git repository
>  and treating it either as a submodule or a subtree-merge?

Personally, I think it would be good enough to split out the os-lib
into its own repo using "git-filter-branch --subdirectory-filter", and
then link to it in newer versions of your crawler and indexer projects
using git-submodule.

There would be a bit of wastage here, since crawler still contains the
history of os-lib, which is the same (even the same tree and file
objects!) as the ones in os-lib.

I can think of two responses to that:

1) It's not very important, disk space is cheap and git repositories
are small, and it's much better to have an accurate history of the
crawler project than to overoptimize for space.

2) If the supermodule and submodule shared the same object repository
(eg. the submodule was checked out with
--alternate=<supermodule-gitdir>), there would be no need to waste
storage space.  If/when I get my act in gear and start submitting
git-submodule patches, supporting this behaviour is the direction I'll
probably start in.
(http://article.gmane.org/gmane.comp.version-control.git/78675)

Have fun,

Avery