Hi Fred,

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 
same time.

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 git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to