Use SVG diagrams instead of EPS ones [hack]

Most of the SVGs are ugly as of now,
and should be brought up to par with the EPS versions still;
see <#3>.

Author: hoijui

text/s1-c00-understanding-git.md

@@ -29,7 +29,7 @@ but instead understood what it was actually doing.
 Then I found I could find new and interesting ways to use
 what is really a very powerful and cool toolset.
 
-![](../artwork/diagrams/what-git-is.eps)
+![](../artwork/diagrams/what-git-is.svg)
 
 So,
 let's see what it's doing behind the scenes first.

text/s1-c03-object-types.md

@@ -35,7 +35,7 @@ that provides very simple bindings to Git,
 keeping the project in a Git repository.
 The basic layout of the project is this:
 
-![Sample project with files and directories](../artwork/diagrams/layout.eps)
+![Sample project with files and directories](../artwork/diagrams/layout.svg)
 
 Let's take a look at what Git does when this is committed to a repository.
 
@@ -44,7 +44,7 @@ Let's take a look at what Git does when this is committed to a repository.
 In Git,
 the contents of files are stored as **blobs**.
 
-![Files are stored as blobs](../artwork/diagrams/blobs.eps)
+![Files are stored as blobs](../artwork/diagrams/blobs.svg)
 
 It is important to note that it is the *contents* that are stored,
 not the files.
@@ -61,13 +61,13 @@ Git will only transfer the blob once,
 then expand it out into multiple files upon checkout.
 
 ![The contents of a blob,
-uncompressed](../artwork/diagrams/blob-expand.eps)
+uncompressed](../artwork/diagrams/blob-expand.svg)
 
 ### The Tree
 
 Directories in Git basically correspond to **trees**.
 
-![Trees are pointers to blobs and other trees](../artwork/diagrams/trees.eps)
+![Trees are pointers to blobs and other trees](../artwork/diagrams/trees.svg)
 
 A tree is a simple list of trees and blobs that the tree contains,
 along with the names and modes of those trees and blobs.
@@ -83,7 +83,7 @@ which shows *mode*,
 *sha* and *name* for each entry (same fields,
 different order).
 
-![An uncompressed tree](../artwork/diagrams/tree-expand.eps)
+![An uncompressed tree](../artwork/diagrams/tree-expand.svg)
 
 ### The Commit
 
@@ -92,22 +92,22 @@ now that we can store arbitrary trees of content in Git,
 where does the 'history' part of 'tree history storage system' come in?
 The answer is the **commit** object.
 
-![A commit references a tree](../artwork/diagrams/commit.eps)
+![A commit references a tree](../artwork/diagrams/commit.svg)
 
 The commit is very simple,
 much like the tree.
 It simply points to a tree and keeps an *author*,
 *committer*,
 *message* and any *parent* commits that directly preceded it.
 
-![Uncompressed initial commit](../artwork/diagrams/commit-expand.eps)
+![Uncompressed initial commit](../artwork/diagrams/commit-expand.svg)
 
 Since this was my first commit,
 there are no parents.
 If I commit a second time,
 the commit object will look more like this:
 
-![A commit with a parent](../artwork/diagrams/commit-expand2.eps)
+![A commit with a parent](../artwork/diagrams/commit-expand2.svg)
 
 Notice how the *parent* in that commit
 is the same SHA-1 value of the last commit we did?
@@ -133,7 +133,7 @@ and the *object* is the SHA-1 of the commit you're tagging.
 The tag can also be GPG signed,
 providing cryptographic integrity to a release or version.
 
-![Uncompressed tag](../artwork/diagrams/tag-expand.eps)
+![Uncompressed tag](../artwork/diagrams/tag-expand.svg)
 
 We'll talk a little bit more about tags
 and how they differ from *branches* (which also point to commits,

text/s1-c05-the-data-model.md

@@ -50,7 +50,7 @@ We'll go over it again later.
 
 The basic data model I've been explaining looks something like this:
 
-![](../artwork/diagrams/dag-model.eps)
+![](../artwork/diagrams/dag-model.svg)
 
 The cheap references I've represented as the grey boxes, the immutable objects are the colored round cornered boxes.
 
@@ -76,7 +76,7 @@ Possibly something like this:
 When we first commit this tree,
 our Git model may look something like this:
 
-![](../artwork/diagrams/object-dag-tree1.eps)
+![](../artwork/diagrams/object-dag-tree1.svg)
 
 We have three trees,
 three blobs and a single commit that points to the top of the tree.
@@ -101,7 +101,7 @@ which adds a new tag object.
 At this point,
 we'll have the following in Git:
 
-![](../artwork/diagrams/object-dag-tree2.eps)
+![](../artwork/diagrams/object-dag-tree2.svg)
 
 Notice how the other two blobs that were not changed were not added again.
 The new trees that were added point to the same blobs in the data store
@@ -116,7 +116,7 @@ Again,
 the branch reference will move forward
 and the new commit will point to its parent.
 
-![](../artwork/diagrams/object-dag-tree3.eps)
+![](../artwork/diagrams/object-dag-tree3.svg)
 
 At this point,
 let's stop to look at the objects we now have in our repository.
@@ -133,7 +133,7 @@ If we wanted the second tree,
 we could ask for the commit pointed to by the tag,
 and so on.
 
-![](../artwork/diagrams/object-dag.eps)
+![](../artwork/diagrams/object-dag.svg)
 
 So,
 to keep all the information and history on the three versions of this tree,
@@ -153,4 +153,4 @@ tag or remote you specify.
 Then it traverses the objects by walking the trees one by one,
 checking out the blobs under the names listed.
 
-![](../artwork/diagrams/traversing-git-objects.eps)
+![](../artwork/diagrams/traversing-git-objects.svg)

text/s1-c06-branching-and-merging.md

@@ -38,7 +38,7 @@ to be the SHA-1 of your last commit).
 
 ### Simple Case
 
-![](../artwork/diagrams/branches1.eps)
+![](../artwork/diagrams/branches1.svg)
 
 Now,
 let's see how Git handles branching,
@@ -54,7 +54,7 @@ We create a new branch called `experiment` off of our main branch,
 which is by convention called `master`.
 We then switch to the new branch and create a few commits.
 
-![](../artwork/diagrams/branch-story1.eps)
+![](../artwork/diagrams/branch-story1.svg)
 
 Then,
 our boss comes in and says we need a hot fix to production.
@@ -64,7 +64,7 @@ push the release and then tag the new commit with the release number.
 Then we go back to our `experiment` branch,
 continue working and commit again.
 
-![](../artwork/diagrams/branch-story2.eps)
+![](../artwork/diagrams/branch-story2.svg)
 
 At this point,
 we show the new branch code to our co-workers
@@ -74,7 +74,7 @@ so we merge the changes and delete our `experiment` branch.
 
 Our history of commit objects now looks like this:
 
-![](../artwork/diagrams/branch-story3.eps)
+![](../artwork/diagrams/branch-story3.svg)
 
 ### Remotes
 
@@ -96,7 +96,7 @@ one to `origin/master` which points to where the master branch was
 on the person's repository you cloned from when you did so,
 and a `master` branch that points to the most recent local commit.
 
-![](../artwork/diagrams/remote-story1.eps)
+![](../artwork/diagrams/remote-story1.svg)
 
 Now let's say you run a `fetch`.
 A fetch pulls all the refs and objects that you don't already have
@@ -113,15 +113,15 @@ and they named the branch `idea` locally,
 then pushed that branch.
 We now have access to those changes as `origin/idea`.
 
-![](../artwork/diagrams/remote-story2.eps)
+![](../artwork/diagrams/remote-story2.svg)
 
 We look at the `idea` branch and like where they're going with it,
 but we also want the changes they've made on their `master` branch,
 so we do a 3-way merge of their two branches and our `master`.
 We don't know how well this is going to work,
 so we make a `tryidea` branch first and then do the merge there.
 
-![](../artwork/diagrams/remote-story3.eps)
+![](../artwork/diagrams/remote-story3.svg)
 
 Now we can run our tests
 and merge everything back into our `master` branch if we want.
@@ -145,7 +145,7 @@ creating a new merge commit.
 (All commits that are simply merges
 are given a darker color in this example)
 
-![](../artwork/diagrams/rebase1.eps)
+![](../artwork/diagrams/rebase1.svg)
 
 At this point,
 you both do work and commit changes
@@ -154,7 +154,7 @@ Then she does another commit and you fetch and merge once more.
 At this point,
 you'll have a commit history that looks something like this:
 
-![](../artwork/diagrams/rebase2.eps)
+![](../artwork/diagrams/rebase2.svg)
 
 Perfectly fine,
 but it can get a little confusing
@@ -181,7 +181,7 @@ since nothing points to them,
 when you run the garbage collection tools
 (see "The Care and Feeding of Git" section).
 
-![](../artwork/diagrams/rebase3.eps)
+![](../artwork/diagrams/rebase3.svg)
 
 So let's see what happens
 if we rebase rather than merge in the same scenario.
@@ -198,22 +198,22 @@ You'll notice that now it looks like she cloned you and committed
 and then you changed that code,
 rather than you both working at the same time and merging.
 
-![](../artwork/diagrams/rebase4.eps)
+![](../artwork/diagrams/rebase4.svg)
 
 At this point,
 instead of merging two more times like we did originally,
 we rebase the next two commits she makes.
 
-![](../artwork/diagrams/rebase5.eps)
+![](../artwork/diagrams/rebase5.svg)
 
-![](../artwork/diagrams/rebase6.eps)
+![](../artwork/diagrams/rebase6.svg)
 
 And finally,
 we are left with a commit history that looks like Figure 1,
 rather than Figure 2,
 which is what we would have if we had merged instead.
 
-![](../artwork/diagrams/rebase7-final.eps)
+![](../artwork/diagrams/rebase7-final.svg)
 
 > **NOTE** \
 You should remember to only do this on local branches before you push

text/s1-c07-treeish.md

@@ -108,7 +108,7 @@ this is the equivalent commit in caret syntax:
 e65s46^^^^^
 ```
 
-![](../artwork/diagrams/treeish.eps)
+![](../artwork/diagrams/treeish.svg)
 
 #### Tree Pointer
 

text/s2-c03-normal-workflow.md

@@ -107,7 +107,7 @@ $ git status
 You can see that if we commit at this point,
 only the Rakefile will show up as changed in the commit.
 
-![](../artwork/diagrams/add-commit.eps)
+![](../artwork/diagrams/add-commit.svg)
 
 If we want to commit all our changes,
 we can use this shorthand,
@@ -118,7 +118,7 @@ then commit the whole thing:
 git commit -a -m 'committing all changes'
 ```
 
-![](../artwork/diagrams/commit-a.eps)
+![](../artwork/diagrams/commit-a.svg)
 
 If you would like to give a more useful commit message,
 you can leave out the `-m` option.

text/s2-c10-tagging.md

@@ -27,7 +27,7 @@ As we recall from section one,
 that command will create a git object
 that looks something like this:
 
-![](../artwork/diagrams/tag-expand.eps)
+![](../artwork/diagrams/tag-expand.svg)
 
 and).
 

text/s2-c11-distributed-workflow.md

@@ -273,7 +273,7 @@ in this case,
 one for every developer with a public fork of that project
 that might push changes I care to try.
 
-![](../artwork/diagrams/fetch-pull.eps)
+![](../artwork/diagrams/fetch-pull.svg)
 
 You can also remove remotes at any time,
 which simply removes the lines
@@ -324,7 +324,7 @@ maybe some permissions tweaked here or there.
 
 There is a single repository that all developers push to and pull from.
 
-![All developers push to a single server](../artwork/diagrams/workflow-star.eps)
+![All developers push to a single server](../artwork/diagrams/workflow-star.svg)
 
 This model works just like a centralized SCM
 and Git can work that way just fine.
@@ -354,7 +354,7 @@ and merged and pushed into the blessed repository,
 where the cycle starts over again.
 
 ![Approved features gradually make their way up the ladder](
-../artwork/diagrams/workflow-dictator.eps)
+../artwork/diagrams/workflow-dictator.svg)
 
 This is a model something like the Linux kernel uses,
 Linus being the benevolent dictator.
@@ -381,7 +381,7 @@ tests,
 accepts and pushes.
 
 ![Private and public repositories driven by read-only pull requests](
-../artwork/diagrams/workflow-integration-manager.eps)
+../artwork/diagrams/workflow-integration-manager.svg)
 
 This is largely how community-based git repositories
 like GitHub were built to work