Patrick.Higgins@xxxxxxxx wrote:
From: Avery Pennarun [mailto:apenwarr@xxxxxxxxx]
Agreed. The first thing we started working on was getting
symlinks out of our repositories.
Unfortunately, we chose to use them because we are using
broken development tools that
don't support proper modularity. We found the best way to
Perhaps git-submodule would do what you're looking for.
We might be able to get by with them, but submodules appear to be
significantly more complex than symlinks, and we sometimes symlink
just a file or two if that's all we need. Splitting up submodules to
that level of granularity would be hard to manage.
My understanding of the submodule workflow is:
Projects A, B, and C (we actually have about 17 of these) all share
common code in project Common. Then, each of A, B, and C adds Common
as a submodule. While working on project A, the need arises to modify
Common, so the developer changes it there, commits, pushes the change
to Common, then commits and pushes the change to A. To update B and
C, they would have to change to each of those projects, run a git
pull, then git submodule update, and compile and test.
Is that correct? If so, it's a lot more work than letting a symlink
propagate the change to all the other projects. Of course, since
Windows doesn't have symlinks...
That is correct, but you only need to do the change if the projects
B, C, D, n... actually requires the new feature/bugfix introduced in
Common. Otherwise you can just leave it as-is.
Besides, when an important bugfix is added to Common, you probably
want to cut new releases from B, C, D, n... anyway, so it still
means doing stuff to those repositories.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
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
