Re: Best way to re-do a CVS repository with git?
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Apr 19, 2008, 22:49 UTC
- Message-ID
- <m3k5itqx2v.fsf@localhost.localdomain>
- In-Reply-To
- <2729632a0804191247t4458067etfc1627a533a84376@mail.gmail.com>
skillzero@gmail.com writes:
Show 10 quoted lines
> On Sat, Apr 19, 2008 at 1:23 AM, Jakub Narebski <jnareb@gmail.com> 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