File file states:
-  Untracked
-  Unmodified
-  Modified
-  Staged
-  Committed

Remotes and branches:
-  origin  -- server you cloned from
-  master  -- main development trunk in local repository;
              master pointer moves forward with each commit to main.
-  HEAD -- pointer to local branch you're currently on.
-  origin/master -- pointer to master branch on server.
   Each clone has origin/master (remote repository) and master (local).

A common scenario (assuming working in master):
-  Two people have clones and make commits.
-  Person A pushes his commits.
-  Person B tries to push his commits, but must do an update first.
-  Person B must do the following:
   git fetch origin
   git merge origin/master
   git push origin master

To make gitk show only zoltan commits:
-  cd Trilinos
   gitk -- packages/zoltan

Commands:

-  git clone software.sandia.gov:/space/git/Trilinos
-  git clone software.sandia.gov:/space/git/preCopyrightTrilinos

-  git status
   Shows which state files are in
   Offers suggestions on how to change state

-  git add <file>
   Adds a file
   Stages a file
   Staging a file marks it as having all conflicts resolved.

-  git reset HEAD <file>
   Unstages a file

-  git diff
   Shows modified vs committed.

-  git diff --staged
   Shows staged vs committed.

-  git diff master...branchname
   See all changes done on branchname; compares with first common ancestor
   between master and branchname.
   Shows only the work the current topic branch has introduced since
   its common ancestor with master.

-  git diff origin..master
   See all changes between what is committed in my repository vs what is in
   the repository on software.sandia.gov.  (master branch for both).

-  git diff origin..
   See all changes between origin/HEAD and what is committed in my repo.

-  git whatchanged --since="12 hours ago" -p
   See what changes were made to the repository in the last 12 hours
   Can use other timeframes, such as "1 day ago."

-  git commit
   Commits all staged files

-  git commit -a
   Commits all modified files

-  git rm <file or wildcard>
   Removes file from tracking
   E.g., git rm \*~
   Note the backslash.

-  git mv <file1> <file2>
   Renames a file

-  git log
   Show history of commits.
     -p       includes diff introduced by commit
     -5       show only the five most recent commits
     --pretty=oneline, short, full, fuller
     --name-only
     --name-status
     --since, --after   commits made after the specified date.
     --until, --before  commits made before the specified date.
     --author           author entry matches the specified string.
     --committer        committer entry matches the specified string.

-  git revert <SHA>
   Revert to a specific version of a public file.

-  git checkout <SHA>
   git reset --hard <SHA>
   Get back (revert) to a previously committed repo
   I needed this sequence of commands when "git pull --rebase" hit conflicts
   and my repo was messed up.  The checkout reverts to the commits before
   the pull; I got the SHA from .git/logs/HEAD, but Siva says it is in gitk,
   too.  The checkout restored my files, but I wasn't on any branch.
   I thought the reset would put me back on a branch, but it didn't.  Hmmm.
   Maybe I should have just done the reset instead of the checkout??

-  git checkout -- <file>
   revert to previously committed version of file

-  git remote -v
   Shows remote repositories

-  git remote show origin
   Shows origin plus branches.

-  git fetch [origin]
   Gets all new work pushed to server since last fetch/clone.
   Doesn't merge with my work, though.  Need manual merge.

-  git pull
   Gets all new work pushed to server since last fetch/clone.
   Attempts a merge on current branch.

-  git pull --rebase
   Gets all new work pushed to server since last fetch/clone.
   Applies the new work so it precedes (instead of follows) the work
   you have committed but not pushed yet.  Preferred way to push committed work.

-  git push [remote] [branch]
   Push committed work to server.

-  git tag
   Lists tags

-  git tag -a "tagname"
   Adds an annotated tag (with much info)

-  git tag "tagname"
   Adds a lightweight tag

-  git checkout -b <name> "tagname"
   Check out from master a tagged version of code to be known
   locally as branch "name"

-  git push origin --tags
   Have to explicitly push tags to origin; they don't go with normal "git push"

-  git push origin origin:refs/heads/HMC_Clinic_2010_Partitioning
   create branch HMC_Clinic_2010_Partitioning at HEAD of origin in global repo

-  git branch <branchname>
   create a branch in local repo

-  git branch -d <branchname>
   delete a branch.

-  git branch
   lists available branches in local clone.

-  git branch -a
   lists all branches available in repository.

-  git branch -v
   lists last commit on each branch.

-  git branch --merged
   lists branches already merged into the HEAD branch.
   git branch --no-merged
   lists branches not yet merged into the HEAD branch.

-  git checkout --track origin/<branchname>
   switch to a branch that you have never switched to before.  Make git
   track that branch for the first time.

-  git checkout <branchname>
   switch to a branch that git is already tracking.

-  git checkout -b <branchname>
   creates a new branch and switches HEAD to it; equivalent to
   git branch <branchname>
   git checkout <branchname>

-  git merge <branchname>
   merge branch into HEAD.

-  git fetch origin
   Updates origin/master pointer with updated files from remote repository.

-  git rebase <branchname>
   Another way to merge.
   Replays changes from <branchname> into HEAD in order they were done,
   rather than merging the endpoints of <branchname> and HEAD.
   !! Do not rebase commits that you have pushed to a public repository. !!
   !! only rebase commits that have never been available publicly.  !!

-  git checkout `git rev-list -n 1 --before="2010-06-22" master`
   Checkout a copy of the code from a given date.

---------------------------------------------------------------------------
How I merged the trilinos-release-10-0-branch with the main trunk

Determine which commits exist.
 git log master..trilinos-release-10-0-branch --pretty=format:"%H - %cn, %cd : %s" -- packages/zoltan > commit_list

This lists the hash, committer name, committer date, and subject of the commit.

Our last CVS merge was Sept. 28, 2009.  I'll merge only commits that occurred
after that date.

Unfortunately, I need to cherry-pick each one.  :(
  git cherry-pick --no-commit -x hash
where hash is one of the hash keys from above.
The -x appends the original commit message, which is nice.
The --no-commit prevent automatic commit if no conflicts.  I like to see
what happened.

To see what happened...See what files were merged.
  git status

If conflicts, resolve and "git add"

Then "git commit".

Repeat for each hash.

The following hashes seemed to have no effect when I followed this procedure;
the comments indicate they actually were transferring files from the main
trunk to the branch, so perhaps there was no difference resulting from the
merge.

bf94764977b44107c5bdddab06a1a2a8dfa38274 - Michael M. Wolf, Thu Oct 8 22:42:04 2009 +0000 :      SUMMARY: Small change to C++ Order function
ab55e6c4872d016be3e5127366b3410a531790f3 - Cedric Chevalier, Wed Oct 7 15:31:16 2009 +0000 :      SUMMARY: Port scotch answer file from the trunk
cadf7e50e5f5b6c7f49b2e05d16eeb6736af824b - Brent M. Perschbacher, Mon Oct 5 18:24:14 2009 +0000 :      SUMMARY:  fix issue with fortran/c interface verify check

Tag the repository with a sanity date.
git tag -a Zoltan_bugmerge_07December2009
git push --tags

--------------------------------------------------------------------------
My former cvss
 git diff --name-only origin/master .
Shows which files differ from the Trilinos repository

--------------------------------------------------------------------------
Brent's tutorial

How to get off a branch
-  Check out a certain hash code.  Make changes and commit.  Pull rebase.
-  Pull rebase, fix conflicts.  Make more changes.  Pull rebase again.
   Have to re-resolve conflicts.
-  Some branch problems...

How to fix your repo when it is off a branch


--------------------------------------------------------------------------
--------------------------------------------------------------------------
Brent's tutorial

------------
If forget to do the config before committing
  do the configuration (git config --global user

Change some files...
  git commit --amend --author 'John Doe <user@domain.tld>'

See Git notes on trilinos web pages for further info.

------------
To make a new local branch...
  git branch new_branch
  git checkout new_branch

To push a branch to the repository...
Push my master branch to repository as branch example_branch
  git push origin master:example_branch
Your branch's changes will be in remotes/origin/example_branch, but not
remotes/origin/master.  They are still in your local master branch.
A "git push" now would put them in origin master.

Or can back up to the content of origin master with
  git reset --hard HEAD~3
where 3 is the number of commits by which you are ahead of origin/master.
The changes you made are still in remotes/origin/example_branch.

Once something is public, don't rebase from before the point where it was
made public.

------------

To merge new_branch onto master
  git checkout master
  git merge new_branch

If have conflicts, can abort the merge
  git merge --abort

Or can fix the conflicts...
  git add filename
  git commit

------------

Collaboration branch

In your cloned Trilinos repo...

see which remotes you have
  git remote -v

Create the remote
  git remote add collab software.sandia.gov:/space/git/collaboration/Trilinos

Get the remote
  git fetch

See all the branches
  git branch -a

Look at the branch with the fix
  git checkout --track remotes/collab/theBugfixBranch


------------
REBASE

Rebase changes history.

When rebasing is dangerous...
Rebasing any commit that is public (e.g., commit that has been pushed,
exists on origin, or has been pulled by someone else from your repo) is BAD.

Karen thinks all her problems were from the following...
  git pull
  make edits
  git commit
  make edits
  git commit
  git pull
  resolve conflicts
  git add
  git commit  (creates a merge commit)
  make edits
  git commit
  make edits
  git commit
  git pull --rebase
  NOW HAVE TO FIX THE SAME CONFLICTS AGAIN -- EEK!

  Can try
    git rebase --abort
  Might leave your commits in a very weird state...they are not attached to
  anything.  Brent and Jim will prototype to see what happens in this case.


Safe ways to use rebase
  reorder commits since origin/HEAD
  squash several commits into one
  drop a commit
  change the commit message
  split commits apart
Doing "git rebase -i SHA" puts you in an editor with instructions;
change the lines in the file.


------------
Finding lost commits:
  git fsck --lost-found
Resoring is easy once you know the SHA; then do
  git cherry-pick SHA
to put the commit back.

------------
When fall off a branch (e.g., because of a rebase or merge),
due to a conflict, fix conflict, git add, git commit (but need a special
command that will be in the original error message), then
  git rebase --continue

Another way to fall off a branch is by checking out a specific SHA (or,
e.g., to origin/master).
Can get back to sane state with "git checkout master"
But if made commits before returning to sane state, want to keep them.
Make a branch at this point
  git branch bad_state
Points to all commits that made during bad state
Then
  git checkout master
  git log HEAD..bad_state  (shows all differences between master and bad_state)
    or git log bad_state   (and visually determine what the differences are)
  git cherry-pick SHA (using SHA from the log command)
