View source for Cjku/git

==Outline==
#[[/backgound_knowledge| Commit graphs]]
#git directory - ref and object store
#git-add and git-commit - manipulate the index and commit tree
#git-reset and git-checkout - manipulate refs, the index and working directory
#Working with remote - distributed system.

Let's discuss merge and rebase in the next session.

==git directory==
===file system===
Figure 1 describe the tree architecture of git directory after clone from a remote.
  <span style="color:grey"># Clone from a repository which has a README.md file and single commit only</span>
  $ git clone https://github.com/CJKu/SingleCommit.git
[[File:Git 1 tree.png|center|thumb|800px|Figure 1. git directory]]

===class diagram===
[[File:Gitclassdiagram.png| center |thumb|800px|Figure 2. git class diagram]]

# Is it possible that a commit does not associate with another object?
#* yes, root commit object
# Is it possible that a commit does not refer to a tree?
#* No, unless you step onto mine
# Is it possible that two commits point to the same tree?
#* Yes. Only if those two commit stay different path of commit graphs.
# Is it possible that HEAD is empty
#* Yes, after git-init before the first commit
# Is it possible that a tree does not refer to any blobs?
#* No, no content no tree. git stores content instead of file.
# Is it possible that a tree point to a commit?
#* No, anti DAG pattern and does not make sense. 
# Is it possible that HEAD refers to branch name directly?
#* Yes, detached branch status.

===object type===
Table 1 roughly describes four different object types. I will explain more detail in the next section. Just keep this table as a reference.
{| class="wikitable"
! style="width:100px; text-align:left;" | Object types
! style="width:600px; text-align:left;" | Description
|-
| Blobs
| Binary large object. Hold '''only''' the content of a file, nothing more.
|-
| Trees
| Be similar to a file system directory. A tree object holds path names and identifiers(SHA1) of blobs and sub-tree objects.
|-
| Commits
| A snapshot of content change, which consist of parent commit(if any), the name of author and comitter, commit message, and identifier(SHA1) of new tree node.
|-
| Tags
| Human readable name of an object.
|}
<span style="color:grey">Table 1. Object types.</span>

===object relation===
In the beginning, let's create a repository, named sample_1, with single commit by following steps. 
  <span style="color:grey">###############################################</span>
  <span style="color:grey">## Create a simple commit graphs
  <span style="color:grey">###############################################</span>
  <span style="color:blue">$ mkdir sample_1 && cd sample_1</span>
  <span style="color:grey"># Initiate git directory.</span>
  <span style="color:blue">$ git init</span>
  <span style="color:blue">$ echo a > a.txt && echo b > b.txt</span>
  <span style="color:blue">$ mkdir sub_dir && echo c > sub_dir/c.txt</span>
  <span style="color:grey"># push a.txt/b.txt/c.txt into the index.</span>
  <span style="color:blue">$ git add --all</span>
  <span style="color:grey"># from the index to a new commit object.</span>
  <span style="color:blue">$ git commit -m "add a.txt, b.txt, c.txt"</span>
  [master (root-commit) 73b1c13] add a.txt, b.txt, c.txt
   3 files changed, 3 insertions(+)
   create mode 100644 a.txt
   create mode 100644 b.txt
   create mode 100644 sub_dir/c.txt
  <span style="color:blue">$ tree .git # or "find .git"</span>
  17 directories, 24 files

[[File:Git 2 object relation.png|thumb|center|800px|Figure 2. object relation]]

Figure 2 depicts the outline of object store. The tree architecture on your device should be exact the same with figure 2, except the name of the commit object, that is because committer and author in your environment differ from mine, which lead to different SHA1.  

The next step is to figure out how many objects was been created and relation among them.
  <span style="color:grey">#######################################################</span>
  <span style="color:grey">## Look into commit/tree/blob objects in object store.
  <span style="color:grey">#######################################################</span>
  <span style="color:grey"># HEAD(symref) refers to current branch, which is master</span>
  <span style="color:blue">$ cat .git/HEAD</span>
  <span style="color:grey">ref: refs/heads/master</span>
  <span style="color:grey"># master(ref) refers to the latest commit object</span>
  <span style="color:blue">$ cat .git/refs/heads/master</span>
  ed0a8533886a3ca5810046506fec786648e89971 # SHA1 of the commit object
  
  <span style="color:grey"># Alternatively, you may use rev-parse command to get SHA1 of the referee, which give you the same result.</span>
  <span style="color:blue">$ git rev-parse HEAD</span>
  ed0a8533886a3ca5810046506fec786648e89971
  <span style="color:blue">$ git rev-parse master</span>
  ed0a8533886a3ca5810046506fec786648e89971
  
  <span style="color:grey"># Read the type of object{ed0a8}. Generally, a branch points to a commit object.</span>
  <span style="color:blue">$ git cat-file -t ed0a8</span>
  <span style="color:red">commit</span>
  
  <span style="color:grey"># Read the content of commit{ed0a8}.</span>
  <span style="color:blue">$ git cat-file -p ed0a8</span>
  tree <span style="color:red">92e349e2e492b65e8137a9b435c5360b51f16f24</span>
   author CJKu <cjcool.tw@gmail.com> 1414401560 +0800
   committer CJKu <cjcool.tw@gmail.com> 1414401560 +0800
  
    add a.txt, b.txt, c.txt
  
  <span style="color:grey"># commit{ed0a8} refers to tree{92e34}. Read content of tree{92e34}.</span>
  <span style="color:blue">$ git cat-file -t 92e34</span>
  <span style="color:red">tree</span>
  <span style="color:blue">$ git cat-file -p 92e34</span>
  100644 blob 78981922613b2afb6025042ff6bd878ac1994e85    a.txt
  100644 blob 61780798228d17af2d34fce4cfbdf35556832472    b.txt
  040000 <span style="color:red">tree</span> cf67e9ef3a0fc6d858423fc177f2fbbe985a6f17    sub_dir
  <span style="color:blue">$ git cat-file -p cf67e</span>
  100644 blob f2ad6c76f0115a6ba5b00456a849810e7ec0af20    c.txt
  
  <span style="color:grey"># Or, use ls-tree -r to dump all blobs in tree.</span>
  <span style="color:blue">$ git ls-tree -r 92e349e</span>
  100644 blob 78981922613b2afb6025042ff6bd878ac1994e85    a.txt
  100644 blob 61780798228d17af2d34fce4cfbdf35556832472    b.txt
  100644 blob f2ad6c76f0115a6ba5b00456a849810e7ec0af20    sub_dir/c.txt

==git-add and git-commit==
   ''Linus Torvalds argued on the Git mailing list that you can’t grasp and fully appreciate the power of 
   Git without first understanding the purpose of the index.''
    - Version Control with Git, 2nd Edition, By: Jon Loeliger; Matthew McCullough, Publisher: O'Reilly Media, Inc.

To prevent confusion, when a git user says
#Cache a file
#Put a file in the index
#Stage a file
All these statements mean the same thing: "I git add a file"

The index(referred as "stage area" sometimes) put things that you proposed for the next commit and does not contain file content. While a git-commit command submit, Git checks the index rather than your working directory to discover what to commit.

Here is a sample of using git-add and git-commit command to modify index and tree object. Figure 3 and 4 reveal git directory changes accordingly.
  <span style="color:blue">$ mkdir git_sample_cache</span>
  <span style="color:blue">$ cd git_sample_cache</span>
  <span style="color:blue">$ git init</span>
  
  <span style="color:grey"># Cache a.txt and b.txt and uses ls-files to peer into index</span>
  <span style="color:blue">$ echo a > a.txt && git add a.txt</span>
  <span style="color:blue">$ echo b > b.txt && git add b.txt</span>
  <span style="color:blue">$ git ls-files --stage</span>
  100644 78981922613b2afb6025042ff6bd878ac1994e85 0       a.txt
  100644 61780798228d17af2d34fce4cfbdf35556832472 0       b.txt
  
  <span style="color:grey"># Summit change. </span>
  <span style="color:blue">$ git commit -m "add"</span>
  [master (root-commit) <span style="color:red">9d262d6</span>] add
   2 files changed, 2 insertions(+)
   create mode 100644 a.txt
   create mode 100644 b.txt
  
  <span style="color:grey"># Look into master-commit-tree chain. </span>
  <span style="color:blue">$ git rev-parse HEAD</span>
  <span style="color:red">9d262d6</span>394b25573fb3287b5cd019281bc8dc3b8
  <span style="color:blue">$ git cat-file -t 9d262d6</span>
  commit
  <span style="color:blue">$ git cat-file -p 9d262d6</span>
  tree <span style="color:red">f4b354863caa9cea99b95422c9dab70465757d87</span>
  author CJKu <cjcool.tw@gmail.com> 1414482450 +0800
  committer CJKu <cjcool.tw@gmail.com> 1414482450 +0800
  
  add
  <span style="color:blue">$git cat-file -t f4b35486</span>
  tree
  <span style="color:blue">$ git cat-file -p f4b354</span>
  100644 blob 78981922613b2afb6025042ff6bd878ac1994e85    a.txt
  100644 blob 61780798228d17af2d34fce4cfbdf35556832472    b.txt
  
  <span style="color:grey"># Modify content of a.txt and cache it. </span>
  <span style="color:blue">$ echo "add a line" >> a.txt</span>
  <span style="color:blue">$ git add a.txt</span>
  
  <span style="color:grey"># Print index. </span>
  <span style="color:blue">$ git ls-files --stage</span>
  100644 <span style="color:red">2915b75977f7d84d291f3329ce1cc251743a7c54</span> 0       a.txt
  100644 61780798228d17af2d34fce4cfbdf35556832472 0       b.txt
  
  <span style="color:blue">$ git commit -m "modify"</span>
  [master <span style="color:red">0492bef</span>] modify
   1 file changed, 1 insertion(+)
  
  <span style="color:grey"># Dig into new created tree.</span>
  <span style="color:blue">$ git cat-file -t 0492bef</span>
  commit
  <span style="color:blue">$ git cat-file -p 0492bef</span>
  tree <span style="color:red">d3de1600ad651843b4659fc896c8686f76841824</span>
  parent <span style="color:red">9d262d6394b25573fb3287b5cd019281bc8dc3b8</span>
  author CJKu <cjcool.tw@gmail.com> 1414483295 +0800
  committer CJKu <cjcool.tw@gmail.com> 1414483295 +0800
  
  modify
  <span style="color:blue">$ git cat-file -t d3de160</span>
  tree
  <span style="color:blue">$ git cat-file -p d3de160</span>
  100644 blob <span style="color:red">2915b75977f7d84d291f3329ce1cc251743a7c54</span>    a.txt
  100644 blob 61780798228d17af2d34fce4cfbdf35556832472    b.txt

[[File:gitcache1.png|thumb|center|800px|Figure 3. cache - add files.]]
[[File:gitcache2.png|thumb|center|800px|Figure 4. cache - modify a file.]]

XXXXXXXXXXXXXXXXXX

To keep what you have changed in working directory to object store, you have to
# Track files you change.
# Cache this tracked file - hash -> generate new blob
# To snapshot the difference between index and current tree, new tree will be created.
# Create a new commit object, which refer to this new tree, and record commit message, author and committer.
All these work can be done by using git-add and git-commit command. However, let's look deeper into commit process. This sample reveals how git appends a vertex into commit graphs.
  <span style="color:grey">###############################################</span>
  <span style="color:grey">## git-commit ~= write-tree + commit-tree + reset</span>
  <span style="color:grey">###############################################</span>
  <span style="color:grey"># There are two commit objects in store</span>
  <span style="color:blue">$ git log --graph --pretty=oneline --abbrev-commit</span>
  * 43cf743 modify
  * 9d262d6 add
  <span style="color:grey"># Reset to the first commit{"add"}, roll back index but don't touch working directory.</span>
  <span style="color:blue">$ git reset --mixed HEAD^</span>
  <span style="color:blue">$ git log --graph --pretty=oneline --abbrev-commit</span>
  * 9d262d6 add
  <span style="color:grey"># Delete orphan objects.</span>
  <span style="color:blue">$ git gc</span>
  <span style="color:grey"># Add a.txt into index again.</span>
  <span style="color:blue">$ git add a.txt</span>
  <span style="color:grey"># Generate a tree object according to index</span>
  <span style="color:blue">$ git write-tree</span>
  <span style="color:red">d3de1600ad651843b4659fc896c8686f76841824</span>
  <span style="color:grey"># Confirm HEAD still refers to commit{SHA1: 9d262}</span>
  <span style="color:blue">$ git log --graph --pretty=oneline --abbrev-commit</span>
  * 9d262d6 add
  <span style="color:grey"># Create a new commit object associate with tree{SHA1: d3de1} and set parent as commit{SHA1: 9d262}</span>
  <span style="color:blue">$ echo -n "modify" | git commit-tree -p 9d262 d3de1</span>
  <span style="color:red">43cf743105b49941565f2295db6cf7aae6f2cdc1</span>
  <span style="color:grey"># Move HEAD to this new commit{SHA1: 43cf7}</span>
  <span style="color:blue">$ git reset --soft 43cf7</span>
  <span style="color:grey"># Done! Check log</span>
  <span style="color:blue">$ git log --graph --pretty=oneline --abbrev-commit</span>
  * 43cf743 modify
  * 9d262d6 add

While index is dirty, your next commit will write those change into object tree, which means git update tree by index in commit process; While checkout to a new branch, git regenerates index by tree object of new branch, which means git updates index by tree in switching branch process. The next two examples explain how git regenerate index via tree.
  <span style="color:grey">###############################################</span>
  <span style="color:grey">## reconstruct index via git-read-tree(plumbing)</span>
  <span style="color:grey">###############################################</span>  
  <span style="color:grey"># Take a look of index's content before wipe it out.</span>
  <span style="color:blue">$ git ls-files -s </span>
  100644 4331a357983b7acf195679e68e543405ef86cc15 0       README.md
  
  <span style="color:grey"># Oops... index files is deleted occasionally.</span>
  <span style="color:blue">$ rm .git/index</span>
  
  <span style="color:grey"># get the identifier of commit object.</span>
  <span style="color:blue">$ git rev-parse HEAD</span>
  <span style="color:grey">46fbc5468dab716b1baf2141b89780586a00556f</span>
  <span style="color:blue">$ git cat-file -p 46fbc54</span>
  tree 57a161d717cf98e78a5eea9a30f313b464fc0429
  author CJKu <cku@mozilla.com> 1414423500 +0800
  committer CJKu <cku@mozilla.com> 1414423500 +0800
  
  Initial commit
  
  <span style="color:grey"># git-read-tree - Reads tree information into the index</span>
  <span style="color:grey"># you can read-tree from a commit object, or the root tree object</span>
  <span style="color:grey"># Let's read from a commit object first<tree-ish>.</span>
  <span style="color:blue">$ git read-tree 46fbc546 </span> 
  
  <span style="color:grey"># Hooray! index file returns back!</span>
  <span style="color:blue">$ git ls-files -s </span>
  100644 4331a357983b7acf195679e68e543405ef86cc15 0       README.md
  
  <span style="color:grey"># Read again from the root tree node.</span>
  <span style="color:blue">$ rm .git/index</span>
  <span style="color:blue">$ git read-tree 57a161d7 </span>
  <span style="color:blue">$ git ls-files -s </span>
  100644 4331a357983b7acf195679e68e543405ef86cc15 0       README.md

In practice, using read-tree plumbing command is not encouraged. Reset, porcelain command, is more promising.
  <span style="color:grey">###############################################</span>
  <span style="color:grey">## reconstruct index via git-reset(porcelain)</span> 
  <span style="color:grey">###############################################</span> 
  <span style="color:grey"># Keep kill index file.</span>
  <span style="color:blue">$ rm .git/index</span>
  
  <span style="color:grey"># git reset [--mixed | --soft | --hardp] [<commit>]</span>
  # --hard    reset HEAD, index and working tree
  # --mixed   reset HEAD and index
  <span style="color:blue">$ git reset --mixed HEAD  </span>
  <span style="color:blue">$ git reset --hard HEAD </span>

==git-reset and git-checkout==
git-checkout and git-reset are a bit confusing at times, at least for me. The functionalities of these two commands are overlapped:
# Both of them are able to move HEAD.
# You can recover what you change in working directory by either of them.

From high level, you may also notice some difference in between
# You can reset HEAD to a commit(a commit-ish) or branch(also, a commit-ish); You can checkout to a commit or a branch as well,  though we usually git-checkout with a branch.
# git-checkout changes the current branch; while reset does not.

[[File: Git reset checkout.png|center|thumb|800px|Figure N. reset and checkout at commit-ish level]]

OK, let's take a look at reset first:
  <span style="color:blue">$ man git-reset</span>
  <span style="color:blue">$ git reset -h</span>
  usage: git reset [--mixed | --soft | --hard] [<commit>]
     or: git reset <tree-ish> [--] <paths>...

<div style="background-color: rgba(250, 255, 240, 1); border-style:dashed; border-width:1px;border-color:grey">
<center>'''Note: what is <tree-ish>'''</center>
The definition of <tree-ish> at [[https://www.kernel.org/pub/software/scm/git/docs/ git-mamual-page]]
*'''<object>''' indicates the object name for any type of object.
*'''<blob>''' indicates a blob object name.
*'''<tree>''' indicates a tree object name.
*'''<commit>''' indicates a commit object name.
*'''<tree-ish>''' indicates a tree, commit or tag object name. A command that takes a <tree-ish> argument ultimately wants to operate on a <tree> object but automatically dereferences <commit> and <tag> objects that point at a <tree>.
*'''<commit-ish>''' indicates a commit or tag object name. A command that takes a <commit-ish> argument ultimately wants to operate on a <commit> object but automatically dereferences <tag> objects that point at a <commit>.

Here are some valid examples of using git-reset command

$ git reset master -- README.txt

$ git reset master^ -- README.txt

$ git reset HEAD -- README.txt

$ git reset v1.0 -- README.txt # v1.0 is a tag name

$ git reset 0a11f0 -- README.txt # 0a11f0 is the name of a commit object

$ git reset 0b7123 -- README.txt # 0b7123 is the name of a tree object

$ git reset refs/heads/master -- README.txt

In short, a tree-ish is a thing that lead a way to a specific tree object. If you give a thing(name/ refname/ tag, ect...) to git, and git can resolve that thing to a unique tree object, then that thing  is a tree-ish. In the following diagram, only the name of a blob is not a tree-ish, since git can not reach any tree object from a blob. I
[[File:Git_treeish.png|center|thumb|800px|Figure N. tree-ish]]
</div>

There are two forms: reset HEAD to a <commit> and reset paths from a <tree-ish>. In the first case, you have tree options(--merge and --keep are ignore here)
  git reset [--mixed | --soft | --hard] [<commit>]

Depend on how hard you want, different change scope applies:
# soft option: change the referee of the current branch
#* index file and working directory keep untouched.
#* scenario: squash.
# mixed option: soft criteria; regenerate index according to the new tree.
#* working directory keeps untouched.
#* scenario: cherry-pick.
# hard option: mixed criteria; Overwrite all '''modified''' tracked files in working directory. (Note: only tracked and dirty files will be overwritten by hard-reset. Unchanged and untracked files are out of scope)
#* scenario: Overtime working, did lots of stupid things
#* scenario: clearing out failed or stale merge

Another usage of reset is to reset paths: 
   git reset [-q] <tree-ish> [--] <paths>

Using it while intending to recover files in working directory from a specific revision. Index or branch ref have nothing to do with this usage. 
  <span style="color:blue">$ echo "Jerry" > a.txt</span>
  <span style="color:blue">$ git add a.txt</span>
  <span style="color:blue">$ git commit -m "initial commit"</span>
  <span style="color:blue">$ echo "is cool" >> a.txt</span>
  <span style="color:blue">$ cat a.txt</span>
  Jerry
  is cool
  <span style="color:grey"># Oops... that is definitely a typo. He is not cool at all.</span>
  <span style="color:blue">$ git reset HEAD -- a.txt</span>
  <span style="color:blue">$ cat a.txt</span>
  Jerry

Now, move forward to checkout command:
  $ git checkout -h
  usage: git checkout [options] <branch>
     or: git checkout [options] [<branch>] -- <file>...

No wonder, there are also two forms in git-checkout: checkout HEAD to a '''branch''' or checkout '''files''' from a '''branch'''. Let's talk about the first form: checkout HEAD to a '''branch''' or checkout
# <span style="color:red">(Different with git-reset)</span> Change the referee(branch) of HEAD.
# <span style="color:red">(Different with git-reset)</span> There is no hardness-choice in git-checkout. git-checkout always modifies working directory and the index. 
# <span style="color:red">(__"Similar"__ to git-reset-hard)</span> Regenerate the index according to the tree of the new assigned commit, and update working directory. There are two places that git-reset-hard is different with git-checkout:
#*First, git-reset-hard never abort, while git-checkout will. 
#*Second, git-reset-hard compares the working directory and new tree, replace all modified tracked files in working directory by content in new tree; if your change in working directory does not cause any conflicts in checkout process, git will not erase the change. If the change indeed causes conflicts, then checkout aborting. Please see the next section for more details

Scott Chacon/Ben Straub wrote a fantastic article with regards to reset, and deserves you spend time on: http://git-scm.com/blog/2011/07/11/reset.html
===checkout abort===
I separate an individual section to discuss git-checkout aborting, since it's somehow annoyed to git new hands. Briefly speaking, if git think you may lose local change in working directory, then checkout abort. 

Longer version. 
  When doing a checkout then Git will check if your working directory is dirty, and if so check 
  if the checkout will result in any conflicts, and if so abort the checkout with a message:
  $ git checkout new_branch
  error: Your local changes to the following files would be overwritten by
  checkout:
         some_file
  Please, commit your changes or stash them before you can switch branches.
  Aborting
  
  If no conflicts then:
  $ git checkout new_branch
  A/D/M    some_file
  Switched to branch 'new_branch' 

What is so called "conflict"? There are three factors, at least, impact logic of "conflict test"

  Factor A: the file, you change/ add/ remove, exists in the new branch
  Factor B: the file, you change/ add/ remove, is the same in two branches
  Factor C: whether you cache the change

# Modify a file: 
#* A[Yes] B[Yes] C[Yes] Pass. After checkout done, keep change in working directory, clear change in the cache.
#* A[Yes] B[Yes] C[No]  Pass. After checkout done, keep change in working directory.
#* A[Yes] B[No]  C[Yes] Abort.
#* A[Yes] B[No]  C[No]  Abort.
#* A[No]  B[N/A] C[Yes] Abort.
#* A[No]  B[N/A] C[No]  Abort.
# Add a file:
#* A[Yes] B[Yes] C[Yes] Pass. After checkout done, keep change in working directory, clear change in the cache.
#* A[Yes] B[Yes] C[No]  Abort.
#* A[Yes] B[No]  C[Yes] Abort.
#* A[Yes] B[No]  C[No]  Abort.
#* A[No]  B[N/A] C[Yes] Pass. After checkout done, keep change in working directory, <span style="color:red">T.T keep change in the cache.</span>
#* A[No]  B[N/A] C[No]  Pass. After checkout done, keep change in working directory.
# Delete a file:
#* A[Yes] B[Yes] C[Yes] Pass. After checkout done, keep change in working directory, <span style="color:red">T.T keep change in the cache.</span>
#* A[Yes] B[Yes] C[No]  Pass. After checkout done, keep change in working directory.
#* A[Yes] B[No]  C[Yes] Abort.
#* A[Yes] B[No]  C[No]  Pass. After checkout done, <span style="color:red">clear</span> change in working directory.
#* A[No]  B[N/A] C[Yes] Pass. After checkout done, keep change in working directory, clear change in the cache.
#* A[No]  B[N/A] C[No]  Pass. After checkout done, keep change in working directory.

10 out of 18 cases pass conflict test. 2 of these 10 cases keep your change in cache. In 1 of these 10 cases, you still lose the change in working directory immidiately after checkout, very 囧 ... If you checkout from a dirty branch with no conflict, many unexpected symptoms appears. Such as commit an unexpected file which was added from another branch. My suggestion is create a git alias, do some status checking before checkout. May refer to http://goo.gl/SVNMtW

So, how to resolve aborting? Different strategies for different situations
# Force checkout: if you don't care change lose at all, use "git checkout -f <branch>" bravely.
# Hard reset: almost the same with previous one. Reset hardly and checkout again.
# Checkout merge: If you want to bring what you change in working directory into the new branch, choose this one. With --merge option, a three-way merge between the current branch, your working directory, and the new branch is done, and you will be on the new branch. And for sure, you have to fix conflicts if any on the new branch.
# Commit change: keep everything you change into object store by a new commit, then checkout again
# Stash: you need to rush into another branch to fix emergency thing. You want to keep the context of current working directory, the index and the tree, use "git stash save" and "git stash pop".

==Remote branch==
===clone===
[[File:Git remote repository.png|thumb|center|800px|Figure 3. Remote and local]]

  $ git clone -h
  usage: git clone [options] [--] <repo> [<dir>]
  -o, --origin <name>   use <name> instead of 'origin' to track upstream

The git-clone command creates a new git repository based on the original you specify.  The branches under refs/heads namespace in original repository become branches under refs/remote/heads namespace in the new created repository. If you do not specify origin in git-clone operation, git use "ref/remote/heads/origin" as default namespace to keep remote-tracking branches. There is no special-power for "origin", it just a default choice. 

Here are roles when we play around with remote:
* Remote repository: the repository you cloned from.
* Remote: short name of URL, or, alias name of URL
* Local/current repository: new repository, create in git-clone procedure, at local side 
* Remote-tracking branches: branches which are associated with a remote. A proxy/ mirror branch of peer branch on the remote.
* A local-tracking branch: a branch that is paired with a remote-tracking branch. It is a form of integration branch that collects both the changes from your local development and the changes from the remote-tracking branch.
* A topic/ development branch: A local branch which is checkout from a local-tracking branch. A development branch is where we construct feature or fix bugs.
* A remote branch: a branch located in remote repository.

===fetch and push===
TBD: refspec

==Recipes/ Troubles==
List troubles that you met while using git. Why this vcs drives you crazy? :)

==Questions==
Please list questions that you want to ask here.

==Reference==
#Version Control with Git, 2nd Edition, By: Jon Loeliger; Matthew McCullough, Publisher: O'Reilly Media, Inc.
#Git Recipes: A Problem-Solution Approach, By: Włodzimierz Gajda, Publisher: Apress
#https://github.com/git/git/blob/master/Documentation/gittutorial.txt
#https://github.com/git/git/blob/master/Documentation/gittutorial2.txt
#https://github.com/git/git/blob/master/Documentation/gitcore-tutorial.txt
#http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/
#http://git-scm.com/blog/2011/07/11/reset.html
#http://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git
#http://git-scm.com/blog/2010/03/08/rerere.html
#http://www.gitguys.com/topics/whats-the-deal-with-the-git-index/
#http://alblue.bandlem.com/2011/10/git-tip-of-week-understanding-index.html
#Directed acyclic graph, http://en.wikipedia.org/wiki/Directed_acyclic_graph
#tree-ish and commit-ish, https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html#_specifying_revisions
#tree-ish and commit-ish, https://www.kernel.org/pub/software/scm/git/docs/
#checkout conflict, http://stackoverflow.com/questions/22609566/how-to-force-git-to-abort-a-checkout-if-working-directory-is-not-clean-i-e-dis
#checkout conflict request, http://git.661346.n2.nabble.com/Git-feature-request-Option-to-force-Git-to-abort-a-checkout-if-working-directory-is-dirty-i-e-disreg-td7606840.html