Soyoung
Soyoung

Reputation: 21

Organizing External Libs in Git for Several Projects

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

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.

Upvotes: 2

Views: 403

Answers (1)

Adam Dymitruk
Adam Dymitruk

Reputation: 129782

Submodules are designed for this. Please learn them. The ProGit.org/book is a great resource. See Chapter 6 section 6 (I've committed that to memory).

I'd be glad to help over twitter/email if you have any other questions. Same id as the one I use here.

Upvotes: 1

Related Questions