Re: Making submodules easier to work with

[Roman Shaposhnik <rvs@sun.com>]

On Thu, 2008-05-01 at 15:55 -0400, Avery Pennarun wrote:
> >  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.

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?

Thanks,
Roman.