Patrick.Higgins@cexp.com wrote:
quoted text
>> From: Avery Pennarun [mailto:apenwarr@gmail.com]
>> 
>>> 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@op5.se
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html