ClearCase vs. Git version control

Question

We are using a multisite ClearCase repository, and often we require to merge and build our system. This merge and replication takes almost three days to be available across sites. Hence to be more efficient, we are planning to move to Git version control. Could you please advise of the potential drawback that we can encounter if we move to the Git from ClearCase?

Answer 1

@zzz777: Your question was asked in such a ClearCase centric view that it failed to be comprehensible to people who never used ClearCase before. In fact, Git is light years ahead of ClearCase, and it is the commercial SCMs that need to catch up with OSS systems.

I have experience with both ClearCase and Git, and I can tell you that the Find merges (mis)feature of ClearCase is a result of its (fundamentally broken) design based on versioning files, but in Git you don't need such a primitive tool to merge the shared branch to your private branch. ClearCase is file-oriented, and checkin-s are file based, and that's why you need the Find (files) to merge utility, but Git is commit based, and that is the right model, since when you fix an issue or implement a feature, the entire changeset or none of it are the only options that make sense.

Git has a very powerful merge feature, and it does the right thing. There are two ways to do what you are asking (updating your private branch to be the shared branch + your changes).

The most obvious is to do a merge, so while on your private branch you just do:

git merge sharedbranch

then, if there are conflicts (really a lot more rare than in ClearCase), you resolve them and

git commit

And that's it. As a bonus, because Git has all history locally, you don't have to waste countless hours, if you have lots of files, like you do in ClearCase, the merge is blazingly fast, by the time ClearCase in a dynamic view does a merge of 10 files, Git will probably finish merging 100, easily.

Using git merge means that you preserve history and if your history looked like this before the merge:

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

after the merge it will look like this:

o---1---2---3 (sharedbranch)
 \           \
  a---b---c---m (privatebranch)

This preserves the history of your changes and can allow others to review your work.

And remember, these are NOT file revision histories. These if the tree history, which is the only history that makes sense to store, even if branches differ only by one or two files. The state you want to preserve is the tree, not one file.

The second option is to use rebase, which means that you make it like it seems al your changes have been made starting from the latest code on the shared branch.

The command you use (again, while on the private branch):

git rebase sharedbranch

The history tree will change from:

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

to

o---1---2---3 (sharedbranch)
             \
              a'--b'--c' (privatebranch)

So if you give Git some time to understand it, and use it a little, you'll see how much better is the Git model and how broken the ClearCase model is.

BTW, the evil twin problem in ClearCase simply does not exist in Git because Git does not track directories (trust me, you do not need that).

Also, if you ever had a configuration specification, which is a little more complicated with several branches and you migrated files from one branch to the other, you probably know how important the order of the rules in the configuration specification is, and how frustrating is to see old versions of files because the configuration specification is "wrong". That happens in ClearCase due to its base design, and, needless to say, that kind of crap can't happen in Git.

So, to conclude, Git does not have a primitive tool such as "find merge", because it does not need it. It has a superior model and superior merge model which actually works. It is lightning fast compared to ClearCase (CCRC static view or dynamic view, you name it).

The only place ClearCase could have an edge is the instantaneous update of the dynamic view, but that is also mitigated by the fact that you can type faster git checkout branch than you can update the configuration specification.