martingodugu · November 27, 2019 13:08
diff --git a/ClearCase_to_Git.txt b/ClearCase_to_Git.txt
 Create new "clean" Snapshot View (call it username_r7_prestine)
 Go to new directory (username_r7_prestine)
 git init
 git config --global user.name "Your Name"
 git config --global user.email you@example.com
 git add .
 git commit -am "Initial Import"
 from view folder
    git clone username_r7_prestine username_r7_git
 from r7_2_int
    add r7_2_int_git as remote
 from r7_1_int/png
    run setup.sh
    cp *.properties /cygdrive/c/view/username_r7_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
diff --git a/cs_to_git_workflow.txt b/cs_to_git_workflow.txt
 To get changes from ClearCase

 Go to "prestine" ClearCase view.
 Update View
 git commit -am "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
diff --git a/git_aliases.txt b/git_aliases.txt
 alias.ci=commit
 alias.remotedir=!git remote -v | awk '/(fetch)/ {print $2}'

 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
diff --git a/gitignore.txt b/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/
diff --git a/gitworkflow.txt b/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”:
 git push
	Create new "clean" Snapshot View (call it username_r7_prestine)
	Go to new directory (username_r7_prestine)
	git init
	git config --global user.name "Your Name"
	git config --global user.email you@example.com
	git add .
	git commit -am "Initial Import"
	from view folder
	git clone username_r7_prestine username_r7_git
	from r7_2_int
	add r7_2_int_git as remote
	from r7_1_int/png
	run setup.sh
	cp *.properties /cygdrive/c/view/username_r7_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
	To get changes from ClearCase

	Go to "prestine" ClearCase view.
	Update View
	git commit -am "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
	alias.ci=commit
	alias.remotedir=!git remote -v \| awk '/(fetch)/ {print $2}'

	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
	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/
	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”:
	git push