Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT compile errors after update from CVC

On 3 Mar 2010, at 15:19, Michael Jackson wrote:

> Replying off list because my next question is really off topic for CDT.  I have a few current projects that all reference the same source codes. Currently I have to copy/paste between all the projects to keep things synced up. I would really just like to have a single small git repo with the couple of source files in it which I can do, but then all those projects now need to sync with 2 repositories and all that. Can I have a sub-project, like a subdirectory within a project be a git submodule? You allude to this NOT being a normal case above but was wondering how much trouble this is.

Let's say you have two projects, and they both need a shared Utility project which you want to keep up to date between the two.

My advice would be to have 3 git repositories; one each for the two projects, and one for the shared project. You could then use your build system to check out files specific to that project, and use cross-workspace references. You could have a parent git project if you want, but it wouldn't be necessary. 

Another example is where you have a 'base' project, but then have two customisations for specific customers. So we have Generic Project, and then Customer Project A, Customer Project B where most of the files are the same between A, B and Generic project, except that maybe a few files differe (e.g. logo.jpg, style.css etc.). 

In the second example, I'd again have 3 Git repositories; but rather than the Customer Project A being just A's files, I'd pull the contents of Generic into A. Similarly, I'd pull the contents of Generic into B as well. That way, as Generic progresses, I can just execute a pull into A (or into B) to bring myself up to the current HEAD version. This is akin to having a local checkout of a project where you have some uncommitted changes that you don't want to commit back to the parent repository - in fact, in this example, you'd probably never want to push from A to Generic or B to Generic.

Both of those are possible without using Git submodules. That's not to say a Git submodule approach doesn't/can't work; you could use it in both cases if you wanted to. It's just that it's not really necessary most of the time.

Lastly, to address your specific point; the parent git project *can* have its own source files if you want to. When you do a commit on the parent Git repository, it will commit just those files. However, the reason for recommending against it in the CDT case is that with many submodules, checking out a parent Git repository will take significant space/time - and if you put content in that project as well, you have to check out the submodules in order to work.

Really, a DVCS allows you to pull/push files from place to place which negates the need for the submodule approach in most cases - it's just that before you get used to the way that DVCS works, it's difficult to know how to use it properly :-) 

Alex

PS Answering on-list because your query did in fact go to the list :-)

http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg17512.html 

Back to the top