got a good amount of the first section done or imported from the user guide

Author: schacon

TODO.markdown

@@ -10,7 +10,6 @@
 
 ===Introduction
 
-* Introduction (Why Git)
 * Git Object DB Basics (Git vs SVN, what is a DAG)
 * The Git Index
 * Git directory and working directory
@@ -55,7 +54,6 @@
 * Git Hooks
 * Git Recovery – corrupted blob objects
 * Advanced Merging – multiway, merge subtree
-* Git Submodules
 
 ===Working With Git
 

layout/pdf_template.html

@@ -11,14 +11,49 @@
 
 	<div class="titlepage">
 	<h1 class="no-toc">Git Community Book</h1>
-	<h2 class="no-toc">What's New</h2>
-
-	<p class="no-toc">by Scott Chacon</p>
-	<!-- also, the publisher's name would typically be printed here -->
+	<h2 class="no-toc"></h2>
+	<p class="no-toc">The open Git resource pulled together by the whole community</p>
 	</div>
 
 	<div class="imprint">
-		<p>Scott Chacon<br/>Website: www.jointheconversation.org</p>
+	  <h2>Authors</h2>
+	  Thank these guys:
+		<p>
+		Andy Parkins (andyparkins@gmail.com),
+    Arjen Laarhoven (arjen@yaph.org),
+    Brian Hetro (whee@smaertness.net),
+    Carl Worth (cworth@cworth.org),
+    Dan McGee (dpmcgee@gmail.com),
+    David Kastrup (dak@gnu.org),
+    Gerrit Pape (pape@smarden.org),
+    Gustaf Hendeby (hendeby@isy.liu.se),
+    J. Bruce Fields (bfields@fieldses.org),
+    Jakub Narebski (jnareb@gmail.com),
+    Jim Meyering (jim@meyering.net),
+    Johan Herland (johan@herland.net),
+    Johannes Schindelin (Johannes.Schindelin@gmx.de),
+    Josh Triplett (josh@freedesktop.org),
+    Junio C Hamano (gitster@pobox.com),
+    Marcus Fritzsch (m@fritschy.de),
+    Michael Coleman (tutufan@gmail.com),
+    Michael Smith (msmith@cbnco.com),
+    Mike Coleman (tutufan@gmail.com),
+    Miklos Vajna (vmiklos@frugalware.org),
+    Oliver Steele (steele@osteele.com),
+    Pavel Roskin (proski@gnu.org),
+    Ralf  Wildenhues (Ralf.Wildenhues@gmx.de),
+    Scott Chacon (schacon@gmail.com),
+    Sergei Organov (osv@javad.com),
+    Shawn Bohrer (shawn.bohrer@gmail.com),
+    Steffen Prohaska (prohaska@zib.de),
+    William Pursell (bill.pursell@gmail.com)
+    </p>
+    
+    <h2>Maintainer / Editor</h2>
+	  Bug this guy:
+	  <p>
+	    Scott Chacon (schacon@gmail.com)
+	  </p>
 	</div>
 
 	<div class="chapter">

text/01_Introduction/0_ Introduction.markdown

@@ -43,9 +43,11 @@ and send me a patch or a pull-request.
 
 ### References ###
 
-Much of this book is pulled together from different sources.
+Much of this book is pulled together from different sources and then added to.  
+If you would like to read some of the original articles or resources, please
+visit them and thank the authors:
 
 * [Git User Manual](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html)
 
 * ["My Git Workflow" blog post](http://osteele.com/archives/2008/05/my-git-workflow)
-(Oliver Steele <steele@osteele.com>)
+

text/01_Introduction/2_Git_Terms.markdown

@@ -0,0 +1,21 @@
+## Some Terms ##
+
+There are a number of terms used in Git that may be new to you.  We're going
+to do a brief overview here to start to get you used to them before we really
+get into it.
+
+* Repo
+* Blob
+* Tree
+* Commit
+* Tag
+* Object
+* Ref
+* Clone
+* Branch
+* Remote
+* Index
+* Working Directory
+* Git Directory
+
+(!!TODO - fill in terms)

text/02_Git_Object_Db_Basics/0_ Git_Object_Db_Basics.markdown

@@ -1 +1,41 @@
-##Git Object Db Basics
+## The Git Object Database ##
+
+We already saw in <<understanding-commits>> that all commits are stored
+under a 40-digit "object name".  In fact, all the information needed to
+represent the history of a project is stored in objects with such names.
+In each case the name is calculated by taking the SHA1 hash of the
+contents of the object.  The SHA1 hash is a cryptographic hash function.
+What that means to us is that it is impossible to find two different
+objects with the same name.  This has a number of advantages; among
+others:
+
+- Git can quickly determine whether two objects are identical or not,
+  just by comparing names.
+- Since object names are computed the same way in every repository, the
+  same content stored in two repositories will always be stored under
+  the same name.
+- Git can detect errors when it reads an object, by checking that the
+  object's name is still the SHA1 hash of its contents.
+
+(See <<object-details>> for the details of the object formatting and
+SHA1 calculation.)
+
+There are four different types of objects: "blob", "tree", "commit", and
+"tag".
+
+- A <<def_blob_object,"blob" object>> is used to store file data.
+- A <<def_tree_object,"tree" object>> ties one or more
+  "blob" objects into a directory structure. In addition, a tree object
+  can refer to other tree objects, thus creating a directory hierarchy.
+- A <<def_commit_object,"commit" object>> ties such directory hierarchies
+  together into a <<def_DAG,directed acyclic graph>> of revisions--each
+  commit contains the object name of exactly one tree designating the
+  directory hierarchy at the time of the commit. In addition, a commit
+  refers to "parent" commit objects that describe the history of how we
+  arrived at that directory hierarchy.
+- A <<def_tag_object,"tag" object>> symbolically identifies and can be
+  used to sign other objects. It contains the object name and type of
+  another object, a symbolic name (of course!) and, optionally, a
+  signature.
+
+The object types in some more detail:

text/02_Git_Object_Db_Basics/1_Trees_and_Blobs.markdown

@@ -0,0 +1,61 @@
+### Tree Object ###
+
+The ever-versatile linkgit:git-show[1] command can also be used to
+examine tree objects, but linkgit:git-ls-tree[1] will give you more
+details:
+
+    $ git ls-tree fb3a8bdd0ce
+    100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c    .gitignore
+    100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d    .mailmap
+    100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3    COPYING
+    040000 tree 2fb783e477100ce076f6bf57e4a6f026013dc745    Documentation
+    100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200    GIT-VERSION-GEN
+    100644 blob 289b046a443c0647624607d471289b2c7dcd470b    INSTALL
+    100644 blob 4eb463797adc693dc168b926b6932ff53f17d0b1    Makefile
+    100644 blob 548142c327a6790ff8821d67c2ee1eff7a656b52    README
+    ...
+
+As you can see, a tree object contains a list of entries, each with a
+mode, object type, SHA1 name, and name, sorted by name.  It represents
+the contents of a single directory tree.
+
+The object type may be a blob, representing the contents of a file, or
+another tree, representing the contents of a subdirectory.  Since trees
+and blobs, like all other objects, are named by the SHA1 hash of their
+contents, two trees have the same SHA1 name if and only if their
+contents (including, recursively, the contents of all subdirectories)
+are identical.  This allows git to quickly determine the differences
+between two related tree objects, since it can ignore any entries with
+identical object names.
+
+(Note: in the presence of submodules, trees may also have commits as
+entries.  See <<submodules>> for documentation.)
+
+Note that the files all have mode 644 or 755: git actually only pays
+attention to the executable bit.
+
+### Blob Object ###
+
+You can use linkgit:git-show[1] to examine the contents of a blob; take,
+for example, the blob in the entry for "COPYING" from the tree above:
+
+    $ git show 6ff87c4664
+
+     Note that the only valid version of the GPL as far as this project
+     is concerned is _this_ particular version of the license (ie v2, not
+     v2.2 or v3.x or whatever), unless explicitly otherwise stated.
+    ...
+
+A "blob" object is nothing but a binary blob of data.  It doesn't refer
+to anything else or have attributes of any kind.
+
+Since the blob is entirely defined by its data, if two files in a
+directory tree (or in multiple different versions of the repository)
+have the same contents, they will share the same blob object. The object
+is totally independent of its location in the directory tree, and
+renaming a file does not change the object that file is associated with.
+
+Note that any tree or blob object can be examined using
+linkgit:git-show[1] with the <revision>:<path> syntax.  This can
+sometimes be useful for browsing the contents of a tree that is not
+currently checked out.

text/02_Git_Object_Db_Basics/2_Commits.markdown

@@ -0,0 +1,48 @@
+### Commit Object ###
+
+The "commit" object links a physical state of a tree with a description
+of how we got there and why.  Use the --pretty=raw option to
+linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
+commit:
+
+    $ git show -s --pretty=raw 2be7fcb476
+    commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4
+    tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf
+    parent 257a84d9d02e90447b149af58b271c19405edb6a
+    author Dave Watson <dwatson@mimvista.com> 1187576872 -0400
+    committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700
+
+        Fix misspelling of 'suppress' in docs
+
+        Signed-off-by: Junio C Hamano <gitster@pobox.com>
+
+As you can see, a commit is defined by:
+
+- a tree: The SHA1 name of a tree object (as defined below), representing
+  the contents of a directory at a certain point in time.
+- parent(s): The SHA1 name of some number of commits which represent the
+  immediately previous step(s) in the history of the project.  The
+  example above has one parent; merge commits may have more than
+  one.  A commit with no parents is called a "root" commit, and
+  represents the initial revision of a project.  Each project must have
+  at least one root.  A project can also have multiple roots, though
+  that isn't common (or necessarily a good idea).
+- an author: The name of the person responsible for this change, together
+  with its date.
+- a committer: The name of the person who actually created the commit,
+  with the date it was done.  This may be different from the author, for
+  example, if the author was someone who wrote a patch and emailed it
+  to the person who used it to create the commit.
+- a comment describing this commit.
+
+Note that a commit does not itself contain any information about what
+actually changed; all changes are calculated by comparing the contents
+of the tree referred to by this commit with the trees associated with
+its parents.  In particular, git does not attempt to record file renames
+explicitly, though it can identify cases where the existence of the same
+file data at changing paths suggests a rename.  (See, for example, the
+-M option to linkgit:git-diff[1]).
+
+A commit is usually created by linkgit:git-commit[1], which creates a
+commit whose parent is normally the current HEAD, and whose tree is
+taken from the content currently stored in the index.

text/02_Git_Object_Db_Basics/3_Trust_and_Tags.markdown

@@ -0,0 +1,53 @@
+### Trust ###
+
+If you receive the SHA1 name of a blob from one source, and its contents
+from another (possibly untrusted) source, you can still trust that those
+contents are correct as long as the SHA1 name agrees.  This is because
+the SHA1 is designed so that it is infeasible to find different contents
+that produce the same hash.
+
+Similarly, you need only trust the SHA1 name of a top-level tree object
+to trust the contents of the entire directory that it refers to, and if
+you receive the SHA1 name of a commit from a trusted source, then you
+can easily verify the entire history of commits reachable through
+parents of that commit, and all of those contents of the trees referred
+to by those commits.
+
+So to introduce some real trust in the system, the only thing you need
+to do is to digitally sign just 'one' special note, which includes the
+name of a top-level commit.  Your digital signature shows others
+that you trust that commit, and the immutability of the history of
+commits tells others that they can trust the whole history.
+
+In other words, you can easily validate a whole archive by just
+sending out a single email that tells the people the name (SHA1 hash)
+of the top commit, and digitally sign that email using something
+like GPG/PGP.
+
+To assist in this, git also provides the tag object...
+
+### Tag Object ###
+
+A tag object contains an object, object type, tag name, the name of the
+person ("tagger") who created the tag, and a message, which may contain
+a signature, as can be seen using linkgit:git-cat-file[1]:
+
+    $ git cat-file tag v1.5.0
+    object 437b1b20df4b356c9342dac8d38849f24ef44f27
+    type commit
+    tag v1.5.0
+    tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000
+
+    GIT 1.5.0
+    -----BEGIN PGP SIGNATURE-----
+    Version: GnuPG v1.4.6 (GNU/Linux)
+
+    iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
+    nLE/L9aUXdWeTFPron96DLA=
+    =2E+0
+    -----END PGP SIGNATURE-----
+
+See the linkgit:git-tag[1] command to learn how to create and verify tag
+objects.  (Note that linkgit:git-tag[1] can also be used to create
+"lightweight tags", which are not tag objects at all, but just simple
+references whose names begin with "refs/tags/").

text/03_The_Git_Index/0_ The_Git_Index.markdown

@@ -1 +1,54 @@
-##The Git Index
+## The Git Index ##
+
+The index is a binary file (generally kept in .git/index) containing a
+sorted list of path names, each with permissions and the SHA1 of a blob
+object; linkgit:git-ls-files[1] can show you the contents of the index:
+
+    $ git ls-files --stage
+    100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0	.gitignore
+    100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0	.mailmap
+    100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0	COPYING
+    100644 a37b2152bd26be2c2289e1f57a292534a51a93c7 0	Documentation/.gitignore
+    100644 fbefe9a45b00a54b58d94d06eca48b03d40a50e0 0	Documentation/Makefile
+    ...
+    100644 2511aef8d89ab52be5ec6a5e46236b4b6bcd07ea 0	xdiff/xtypes.h
+    100644 2ade97b2574a9f77e7ae4002a4e07a6a38e46d07 0	xdiff/xutils.c
+    100644 d5de8292e05e7c36c4b68857c1cf9855e3d2f70a 0	xdiff/xutils.h
+
+Note that in older documentation you may see the index called the
+"current directory cache" or just the "cache".  It has three important
+properties:
+
+1. The index contains all the information necessary to generate a single
+    (uniquely determined) tree object.
+
+    For example, running linkgit:git-commit[1] generates this tree object
+    from the index, stores it in the object database, and uses it as the
+    tree object associated with the new commit.
+
+2. The index enables fast comparisons between the tree object it defines
+    and the working tree.
+
+    It does this by storing some additional data for each entry (such as
+    the last modified time).  This data is not displayed above, and is not
+    stored in the created tree object, but it can be used to determine
+    quickly which files in the working directory differ from what was
+    stored in the index, and thus save git from having to read all of the
+    data from such files to look for changes.
+
+3. It can efficiently represent information about merge conflicts
+    between different tree objects, allowing each pathname to be
+    associated with sufficient information about the trees involved that
+    you can create a three-way merge between them.
+
+    We saw in <<conflict-resolution>> that during a merge the index can
+    store multiple versions of a single file (called "stages").  The third
+    column in the linkgit:git-ls-files[1] output above is the stage
+    number, and will take on values other than 0 for files with merge
+    conflicts.
+
+The index is thus a sort of temporary staging area, which is filled with
+a tree which you are in the process of working on.
+
+If you blow the index away entirely, you generally haven't lost any
+information as long as you have the name of the tree that it described.

text/04_Git_Directory_and_Working_Directory/0_ Git_Directory_and_Working_Directory.markdown

@@ -1 +1,5 @@
-##Git Directory and Working Directory
+## Git Directory and Working Directory ##
+
+(explain the git directory)
+
+(explain the working directory)