Question

My company is in the process of changing our version control tool from Rational ClearCase to Git. We have the following development scenario, and we’re curious if there’s a proper pattern to follow with Git to achieve the same behavior we have in ClearCase.

Here are some basic points about our situation:

1. We have a number of discrete applications. Let’s call these AppA, AppB, and AppC.
2. We also have certain files (build scripts, etc.) that are common to all of the projects. Let’s call this Tools.
3. For any given cut of the AppA, AppB, or AppC code, we need a specific cut of the Tools code.
4. Most of our developers never modify the Tools code.

For ClearCase, we’ve modeled this like this:

Components: app_a, app_b, app_c, tools

Projects: AppA, AppB, AppC, Tools

Project AppA includes app_a as a read/write component and tools as a read-only component.

Project AppB includes app_b as a read/write component and tools as a read-only component.

Project AppC includes app_c as a read/write component and tools as a read-only component.

Project Tools includes tools as a read/write component.

Each baseline for the App* projects references a baseline on both the app_* and tools compoments. When developers rebase to the recommended baseline, they pull in changes from both components.

For Git, we think submodules might be the closest thing to the right answer. However, when pulling/rebasing a repository, it sounds like it requires an extra step to update the submodule code. Ideally, we’d like to be transparent. Also, we don’t necessarily care about knowing what changed in a submodule from the viewpoint of the parent repository; we only care about a point in time for the entire submodule.

Answer 1

First, be sure to understand the difference between a (UCM-like) configuration in ClearCase and git (see “Flexible vs static branching (GIT vs Clearcase/Accurev)“).
When looking at the differences between ClearCase and Git, each UCM components must be represented in Git as a repository.

Submodules requires an extra step if modified, as described in “true nature of submodules“.
But they record a specific SHA1, which is what you want when you are pulling each ‘APP‘.
gitslave would allow you to keep Tools more tightly linked with ‘Appx‘, but I don’t think it fits your scenario.

Note that using submodules will:

• make ‘Tools‘ a sub-directory of ‘APPx‘
• make it modifiable.
  There is no “read-only” component with git: if you can access the repo, you can push/pull.
  If you really need to enforce a read-access, then you need to add an extra “authorization layer”, called gitolite.