Re: Making submodules easier to work with

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