Re: Making submodules easier to work with

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 7, 2008, 16:14 UTC
Message-ID: <32541b130805070914n2d090971rf367c838dcfd9557@mail.gmail.com>
In-Reply-To: <1210117622.25663.1110.camel@work.sfbay.sun.com>

On 5/6/08, Roman Shaposhnik <rvs@sun.com> wrote:

Show 10 quoted lines

> 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