On Thu, May 8, 2008 at 12:14 AM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > On 5/6/08, Roman Shaposhnik <rvs@xxxxxxx> 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) > It doesn't change the workflow whether using --alternative (although i think it is a good idea). The most interesting idea in that thread is the "When checking out a submodule, give the submodule's current commit a useful branch name". As a heavy submodule user, this will make my life much easier. -- Ping Yin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
