Organizing External Libs in Git for Several Projects

Question

The Problem

I want my company to store all the included external libs in source control, but I would like these external libs to be in a single repo (not included in each individual project) as there's quite a few libs, and they are large.

Prior Art

This question addresses the problem but no one answered to it directly. (How do I organize my Git repo [better title appreciated])

This pretty well describes a similar situation, but no dice. (Git, sub-repos & external libs for web development - best strategy once and for all?)

This definitely answers the question, but uses submodules. (Best Practice for Git Repositories with multiple projects in traditional n-tier design)

Git Slave sounds great, but I'd prefer to not add another git tool to our repertoire as git is new to us.

This is what I'm thinking so far.

my coding dir/    
    app1/
        .git/
        src/
        com/
        ...
    app2/
        .git/
        src/
        com/
        ...    
    ext libs/
        .git/
        server crap/
            apache tomcat 7.0.123/
                ...
            apache cxf versionnumber/
                ...
        util crap/
            someones really great util lib-1.0/
                ...

And then there would be a $PATH variable in a config or similar that would point to the lib dir.

More thoughts

We don't have an infrastructure engineer, and because I don't want to be on call every time someone needs to add or update a lib, I'd like to shy away from git submodule because it seems gnarly. I'm happy to move to that in the future, but we're only beginning our drink from the git koolaid.
I'm also happy to use submodules now if someone can point me to a clear explanation of what it is and a clear tutorial how to use it so I can pass this info to my peers. I don't want to make everyone read two hours of documentation about advanced topics while we're just now getting on our feet with Git.
It would be nice to link versions of the lib repo with versions of the application repos.

Again, I can be talked out of my anti-submodule sentiment, but the fact that the tutorials I can find are outdated and/or confusing is a big downer. This needs to be an easy process for any engineer, and easy to undo. We are not git ninjas!

Lastly, I don't know if it matters, but we're all on unix, and all java all the time.

Thanks in advance!

Update 3-1-2012

I'm about to make baby Linus Torvalds cry.

I've been doing a fair amount of research, and my conclusion is that submodules are great if you're already a git ninja. So, that said, I'm going to do the wrong thing and create a libs directory in each git project. Why? It's easier, and it's a vast improvement over what we're doing currently. It also assumes a much lower threshold of git knowledge. One day when we're all solid on the basic and intermediate concepts of git (patches? rewriting history? advanced branching?), we'll likely move to submodules. As it stands, I don't want to set my engineers up for failure by giving them too much to chew.

Hopefully between now and when we are ready to move to the "right way", submodules will be less gnar.

Organizing External Libs in Git for Several Projects

Answers (1)

Related Questions