I think there are many of us with experiences from old setups where SCM was
just used wrong :)
Although your idea sounds possible, I'm not sure if it would be good for an
enterprise setup. It kind of sounds like an internal open-source project,
where the project leader accepts patches coming in from a big bunch of
contributors. I don't think this would work internally in a company.
I think you have several problems here, and I'm not sure if it's good to
solve them by going to Git:
1. The workspace of a developer is too big. Working on 50 modules is too
2. The modules are highly coupled, changing one module often includes
changing another, hence the need to keep them all in one workspace.
3. It's not practical to finalize and "release" a module - replacing the
workspace module with a binary (JAR-file, DLL, whatever).
You need to figure out which modules are applications, and which are
libraries used by which applications. Then start treat them as individual
projects. Where this doesn't work, you might have to merge together modules
to single projects.
These are general architectural issues that you'll have to deal
with. Switching SCM might make things work a bit smoother, but won't fix the
above. Depending on your colleagues knowledge of Git, switching might even
make it worse, without proper training, etc.
It always depends on context: But I would rather settle for an approach
where I tried pulling out one library of the workspace (replacing it with a
binary build), and then putting it in a Git repository for starters. This
would serve as a nice trial of how to extract modules, and use Git at the
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at