2

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.

Community
  • 1
  • 1
Soyoung
  • 21
  • 2

1 Answers1

1

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.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • We're super new to git, and the fact that the progit tutorial on submodules is 5 pages is a turn off. If there's a more __concise, clear, and up to date tutorial__, I'm happy to use submodules, [and I know this view is shortsighted] but it seems like the overhead is not worth the effort. Please prove me wrong. I may ping you a little later. – Soyoung Feb 24 '12 at 19:34
  • It's very powerful. Do you expect to use something without reading the manual? It does not take that long to read the tutorial and practice it a bit. If you choose to save time here, you will waste a lot of time in the future and over the long run. Save a penny, lose a dollar. I'm all ears on gtalk too. Also, there are hundreds of people on the #git irc channel. All are willing to hold your hand through any tasks day and night. Hopefully you will evolve your process to something like we have: http://dymitruk.com/blog/2012/02/05/branch-per-feature/ – Adam Dymitruk Feb 24 '12 at 19:48
  • Yes, we do branch per feature. I myself am not worried about reading the manual. I'll do so happily. I'm worried about convincing a squad of engineers to do so and/or giving a tutorial/workshop myself as I don't know the ins and outs of git. That terrifies me. What's concerning there's not a quick and dirty intro to submodules to supplement the long and exhaustive intro to submodules. I suppose that means I'll have to write one myself ;) – Soyoung Feb 24 '12 at 20:22
  • Don't become a bottleneck. Involve others. – Adam Dymitruk Feb 24 '12 at 21:48