Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have some code that uses a library that I and others frequently modify (usually only by adding functions and methods). We each keep a local fork of the library for our own use.

I also have a lot of small "driver" programs (~100 lines) that use the library and are used exclusively by me. Currently, I have both the driver programs and the library in the same repository, because I frequently make changes to both that are logically connected (adding a function to the library and then calling it).

I'd like to merge my fork of the library with my co-workers' forks, but I don't want the driver programs to be part of the merged library.

What's the best way to organize the git repositories for a large, shared library that needs to be merged frequently and a number of small programs that have changes that are connected to changes in the library?

share|improve this question
add comment

2 Answers 2

up vote 4 down vote accepted

Sounds like a good fit for git submodules - move the library into it's own, public repository, then add it as a git submodule to the repository where you keep your driver programs. If you haven't used git submodules, it might take some getting used to; understanding how it works requires some knowledge of git's internals. Here's a tutorial that I found useful.

share|improve this answer
add comment

You could make the library be one repository per developer, so each developer maintains their own fork but can pull from each other.

You could make the library be one shared repository such that commits that go to master are not expected to cause uncommunicated issues for the other developers.

Both of those have a slight complication in that given a version of a driver program it may be difficult to get back to the version of the library; you'd need to decide that's not a problem or start tracking what version your driver programs need.

The other main solution is to do nothing, but as you've seen git isn't well-suited to treating part of a repository as a whole, unlike its centralised slightly cumbersome cousin Subversion.

More specific answers might depend on knowing what language the library and client programs are written in.

share|improve this answer
    
It's C++, and for the most part we only add functions and methods to the library, so breaking compatibility with driver programs shouldn't be a problem. –  Dan Oct 10 '12 at 0:05
1  
Another problem is that the forks haven't been merged in ~4 years. –  Dan Oct 10 '12 at 0:06
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.