Reorganize and expand some topics.

1 files changed, 25 insertions, 14 deletions

diff --git a/git.org b/git.org
index 89616eb..10d72d7 100644
--- a/git.org
+++ b/git.org
@@ -77,6 +77,12 @@
   Git commits contain a tree, its parent commits, and a tree object,
   along with meta-data: message, author, commiter, and so forth.
 
+  In git, a commit can have many parents, as opposed to SVN where a
+  commit can have only one parent. All commits contain a tree, so when
+  you had to resolve conflicts from a merge, those will be contained
+  in the commit's tree object.
+
+
 **** tags
   Tag objects contain a commit id and an optional message and
   cryptographic signature. If neither are present, a tag is merely a
@@ -84,14 +90,15 @@
 
 *** All objects are identified by SHA hashes.
 
-  The unit of history is the commit which can be soley identified by
-  its contents. The hash is easy to compute and provides good entropy
-  properties when building a hash table.
+  The hash table has a number of advantages:
+
+    # since type and length are part of the object you can use one
+      namespace.
 
-**** Some measure of security comes for free
+    # good entropy properties for building hash tables
 
-  All commits are effectively signed by all their previous commits, so
-  verifying a repository becomes trivial given only a valid commit id.
+    # system and its history is trivially verifiable. commits are
+      effectively signed by all their parents.
 
 *** Investigating the object store
 
@@ -100,14 +107,6 @@
 **** There is no delta concept in the object store
    Deltas are generated by `git gc' when it creates pack files.
 
-
-** merge commits
-
-  In git, a commit can have many parents, as opposed to SVN where a
-  commit can have only one parent. All commits contain a tree, so when
-  you had to resolve conflicts from a merge, those will be contained
-  in the commit's tree object.
-
 ** SHA hashes are a pain to type
 
   Git has a concept of `refs' which are typically symbolic references
@@ -147,10 +146,22 @@
 
 *** Remotes
 
+  Remotes are named repositories. They're useful when you push or pull
+  from the same repository repeatedly. The `origin' remote is used as
+  the default remote with many commands.
+
 *** Implicit read-only "vendor" branches.
 
+  When you fetch a remote you get all its objects, so you can always
+  look at any point of its history. This duplicates `vendor branch'
+  functionality.
+
 *** Push and Pull
 
+  You fetch changes via `fetch,' but frequently use `pull' instead,
+  which does a fetch and merge of any remote branches being
+  tracked. To publish changes to a remote, use `push.'
+
 *** Example
 
 * Merge strategies