skillzero@xxxxxxxxx writes: > On Sat, Apr 19, 2008 at 1:23 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > I think that such setup would be best managed by creating Git > > repository for each piece, and "integration" repositories, one for > > apps people, and one for firmware people, using submodule support in > > Git. > > > Tagging entire release would be tagging in "integration" repository, > > the one using submodules. > > Thanks for the info. git submodules seem like the right direction. [cut] I don't know if using submodules is a right solution: git submodules are for more or less loosely tied projects. It is a solution which is worth considering. It allows for example developing some experimental feature in subproject, while superproject use stable, tested version of submodule. Another solution is to merge subproject directly to superproject using 'subtree' merge strategy, like currently gitk and git-gui is maintained/managed in git. Yet another would be to use something similar to Mercurial's fores, or one of earlier submodule implementations, namely git repositories inside working directories in other git repositories. And perhaps you would have to roll your own scripts around git, so single commit would trigger commit in supermodule; that or write your own hook scripts to do that. Unfortunately it seems like nobody interested in your plight... and I cannot help mych beyound that what I've wrote... -- Jakub Narebski Poland ShadeHawk on #git -- 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
