ClearCase <-> Git

ClearCase_to_Git.txt

Create new "clean" Snapshot View (call it r7_2_int)
Go to new directory (r7_2_int)
git init
git config --global user.name "Your Name"
git config --global user.email you@example.com
git add .
git commit -am "Initial Import"
Got to "png" folder
    setup.sh
from view folder
    git clone r7_2_int r7_2_int_git
from r7_2_int
    add r7_2_int_git as remote
from r7_1_int/png
    cp *.properties /cygdrive/c/view/r7_2_int_git/png/
from r7_2_int_git
    emacs .gitignore
    (see gitignore file)
    Be sure to add any new files to .gitignore that you don't want to be checked into ClearCase

cs_to_git_workflow.txt

To get changes from ClearCase

Go to "prestine" ClearCase view.
Update View
git add .   # Don't use just "git commit -am" because that doesn't add new files, only modified files.
git commit -m "Update from CS"
Go to git working directory ( cd $(git remotedir) )
git pull

To send changes to ClearCase

From git working directory
git add/git commit -am
Got to "prestine" ClearCase view ( cd $(git remotedir) )
git pull
convert hijacked files to checkouts
checkin files

git_aliases.txt

alias.ci=commit
alias.remotedir=!git remote -v | awk '/(fetch)/ {print $2}'
alias.root=!pwd

"cd $(git root)" will take you to the root of the repository from anywhere inside it.

SVN-Like
        st = status

        # SVN-compatible versions of commands
        # "foo-svn" is used here instead of "svn-foo" so that it's suggested when people tab-complete "git fo..."
        cherry-pick-svn = !GIT_EDITOR='sed -i /^git-svn-id:/d' git cherry-pick -e
        branch-svn = svn branch
        merge-svn = merge --squash
        push-svn = svn dcommit

        # The next two lines are recommended, as their strengths outweigh their weaknesses.
        # Strength: they make transitioning from SVN easier
        # Weakness: they make teaching `git pull` harder when you move to git on the server
        # Weakness: they encourage people to think that rebasing is a safe default
        up = svn rebase
        update = svn rebase

        # The next line *is not* recommended, as its weaknesses outweigh its strengths.
        # Strength: it makes transitioning from SVN easier
        # Weakness: it makes teaching `git add`, `git commit -a`, the index, etc. harder
        # Weakness: it encourages people to think that a git commit is analogous to an SVN commit
        #ci = commit

gitignore.txt

png/additional-external-config.properties
png/view.properties
*\~
*build/
png/setup.sh
png/ssoapps/company/lib/
png/ssoapps/company/remote/lib/
png/ssoapps/landing/lib/
png/ssoapps/landing/remote/lib/

gitworkflow.txt

To get code from the “remote” repo:
git pull (some choose to do a git fetch and then git merge if necessary, I’ve always just done git pull and it works very reliably)

To see what changes you have locally:
git status

To add files that you’ve changed or created:
git add <file>

That adds it to a stage for committing.  So you aren’t commiting every modified file you have locally, just the ones you want to.  If you want a quick and easy way to just commit all files you’ve modified locally:
git commit –am “message”

The –a is “add all”, essentially.  Now, this doesn’t mean your code is now on the remote.  Unlike SVN and other centralized repos, commit just adds the revision/changeset to your local repo.  You can undo them, branch, and do other manipulations locally before sending them off to the server.  You can do all the same changeset manipulations you would on SVN, but without effecting others.

Once you want your code to be shared with others and on the “remote”:
cd to remote
git pull