fix image paths

Author: schacon

book/07-git-tools/sections/other-helpers.asc

@@ -175,7 +175,7 @@ end
 
 In one branch we change the word ``hello'' to ``hola'', then in another branch we change the ``world'' to ``mundo''.
 
-image::../images/rerere1.png[]
+image::images/rerere1.png[]
 
 When we merge the two branches together, we'll get a merge conflict:
 
@@ -277,7 +277,7 @@ Recorded resolution for 'hello.rb'.
 
 You can see that it "Recorded resolution for FILE".
 
-image::../images/rerere2.png[]
+image::images/rerere2.png[]
 
 Now, let's undo that merge and then rebase it on top of our master branch instead. We can move our branch back by using `reset` as we saw in <<_reset>>.
 
@@ -337,7 +337,7 @@ index a440db6,54336ba..0000000
   end
 ----
 
-image::../images/rerere3.png[]
+image::images/rerere3.png[]
 
 You can also recreate the conflicted file state with the `checkout` command:
 

book/07-git-tools/sections/replace.asc

@@ -22,7 +22,7 @@ c1822cf first commit
 
 We want to break this up into two lines of history.  One line goes from commit one to commit four - that will be the historical one.  The second line will just be commits four and five - that will be the recent history.
 
-image::../images/replace1.png[]
+image::images/replace1.png[]
 
 Well, creating the historical history is easy, we can just put a branch in the history and then push that branch to the master branch of a new remote repository.
 
@@ -37,7 +37,7 @@ c6e1e95 (history) fourth commit
 c1822cf first commit
 ----
 
-image::../images/replace2.png[]
+image::images/replace2.png[]
 
 Now we can push the new `history` branch to the `master` branch of our new repository:
 
@@ -82,7 +82,7 @@ $ echo 'get history from blah blah blah' | git commit-tree 9c68fdc^{tree}
 The `commit-tree` command is one of a set of commands that are commonly referred to as 'plumbing' commands. These are commands that are not generally meant to be used directly, but instead are used by **other** Git commands to do smaller jobs. On occasions when we're doing weirder things like this, they allow us to do really low-level things but are not meant for daily use. You can read more about plumbing commands in <<_plumbing>>
 =====
 
-image::../images/replace3.png[]
+image::images/replace3.png[]
 
 OK, so now that we have a base commit, we can rebase the rest of our history on top of that with `git rebase --onto`.  The `--onto` argument will be the SHA we just got back from `commit-tree` and the rebase point will be the third commit (the parent of the first commit we want to keep, `9c68fdc`):
 
@@ -94,7 +94,7 @@ Applying: fourth commit
 Applying: fifth commit
 ----
 
-image::../images/replace4.png[]
+image::images/replace4.png[]
 
 OK, so now we've re-written our recent history on top of a throw away base commit that now has instructions in it on how to reconstitute the entire history if we wanted to. We can push that new history to a new project and now when people clone that repository, they will only see the most recent two commits and then a base commit with instructions.
 
@@ -154,7 +154,7 @@ c1822cf first commit
 
 Cool, right?  Without having to change all the SHAs upstream, we were able to replace one commit in our history with an entirely different commit and all the normal tools (`bisect`, `blame`, etc) will work how we would expect them to.
 
-image::../images/replace5.png[]
+image::images/replace5.png[]
 
 Interestingly, it still shows `81a708d` as the SHA, even though it's actually using the `c6e1e95` commit data that we replaced it with.  Even if you run a command like `cat-file`, it will show you the replaced data:
 

book/07-git-tools/sections/reset.asc

@@ -90,42 +90,42 @@ $ tree
 
 Git's main purpose is to record snapshots of your project in successively better states, by manipulating these three trees.
 
-image::../images/reset-workflow.png[]
+image::images/reset-workflow.png[]
 
 Let's visualize this process: say you go into a new directory with a single file in it.
 We'll call this *v1* of the file, and we'll indicate it in blue.
 Now we run `git init`, which will create a Git repository with a HEAD reference which points to an unborn branch (`master` doesn't exist yet).
 
-image::../images/reset-ex1.png[]
+image::images/reset-ex1.png[]
 
 At this point, only the Working Directory tree has any content.
 
 Now we want to commit this file, so we use `git add` to take content in the Working Directory and copy it to the Index.
 
-image::../images/reset-ex2.png[]
+image::images/reset-ex2.png[]
 
 Then we run `git commit`, which takes the contents of the Index and saves it as a permanent snapshot, creates a commit object which points to that snapshot, and updates `master` to point to that commit.
 
-image::../images/reset-ex3.png[]
+image::images/reset-ex3.png[]
 
 If we run `git status`, we'll see no changes, because all three trees are the same.
 
 Now we want to make a change to that file and commit it.
 We'll go through the same process; first we change the file in our working directory.
 Let's call this *v2* of the file, and indicate it in red.
 
-image::../images/reset-ex4.png[]
+image::images/reset-ex4.png[]
 
 If we run `git status` right now, we'll see the file in red as ``Changes not staged for commit,'' because that entry differs between the Index and the Working Directory.
 Next we run `git add` on it to stage it into our Index.
 
-image::../images/reset-ex5.png[]
+image::images/reset-ex5.png[]
 
 At this point if we run `git status` we will see the file in green
 under ``Changes to be committed'' because the Index and HEAD differ – that is, our proposed next commit is now different from our last commit.
 Finally, we run `git commit` to finalize the commit.
 
-image::../images/reset-ex6.png[]
+image::images/reset-ex6.png[]
 
 Now `git status` will give us no output, because all three trees are the same again.
 
@@ -138,7 +138,7 @@ The `reset` command makes more sense when viewed in this context.
 
 For the purposes of these examples, let's say that we've modified `file.txt` again and committed it a third time. So now our history looks like this:
 
-image::../images/reset-start.png[]
+image::images/reset-start.png[]
 
 Let's now walk through exactly what `reset` does when you call it. It directly manipulates these three trees in a simple and predictable way.
 It does up to three basic operations.
@@ -149,7 +149,7 @@ The first thing `reset` will do is move what HEAD points to.
 This isn't the same as changing HEAD itself (which is what `checkout` does); `reset` moves the branch that HEAD is pointing to.
 This means if HEAD is set to the `master` branch (ie, you're currently on the `master` branch), running `git reset 9e5e64a` will start by making `master` point to `9e5e64a`.
 
-image::../images/reset-soft.png[]
+image::images/reset-soft.png[]
 
 No matter what form of `reset` with a commit you invoke, this is the first thing it will always try to do.
 With `reset --soft`, it will simply stop there.
@@ -165,7 +165,7 @@ Note that if you run `git status` now you'll see in green the difference between
 
 The next thing `reset` will do is to update the Index with the contents of whatever snapshot HEAD now points to.
 
-image::../images/reset-mixed.png[]
+image::images/reset-mixed.png[]
 
 If you specify the `--mixed` option, `reset` will stop at this point.
 This is also the default, so if you specify no option at all, this is where the command will stop.
@@ -178,7 +178,7 @@ You rolled back to before you ran all your `git add` and `git commit` commands.
 The third thing that `reset` will do is to make the Working Directory look like the Index.
 If you use the `--hard` option, it will continue to this stage.
 
-image::../images/reset-hard.png[]
+image::images/reset-hard.png[]
 
 So let's think about what just happened.
 You undid your last commit, the `git add` and `git commit` commands, **and** all the work you did in your working directory.
@@ -210,20 +210,20 @@ This form (since you did not specify a commit SHA or branch, and you didn't spec
 
 So it essentially just copies `file.txt` from HEAD to the Index.
 
-image::../images/reset-path1.png[]
+image::images/reset-path1.png[]
 
 This has the practical effect of _unstaging_ the file.
 If we look at the diagram for that command and think about what `git add` does, they are exact opposites.
 
-image::../images/reset-path2.png[]
+image::images/reset-path2.png[]
 
 This is why the output of the `git status` command suggests that you run this to unstage a file.
 (See <<_unstaging>> for more on this.)
 
 We could just as easily not let Git assume we meant ``pull the data from HEAD'' by specifying a specific commit to pull that file version from.
 We would just run something like `git reset eb43bf file.txt`.
 
-image::../images/reset-path3.png[]
+image::images/reset-path3.png[]
 
 This effectively does the same thing as if we had reverted the content of the file to *v1* in the Working Directory, ran `git add` on it, then reverted it back to *v3* again (without actually going through all those steps).
 If we run `git commit` now, it will record a change that reverts that file back to *v1*, even though we never actually had it in our Working Directory again.
@@ -242,15 +242,15 @@ You can use `reset` to quickly and easily squash them into a single commit that
 Let's say you have a project where the first commit has one file, the second commit added a new file and changed the first, and the third commit changed the first file again.
 The second commit was a work in progress and you want to squash it down.
 
-image::../images/reset-squash-r1.png[]
+image::images/reset-squash-r1.png[]
 
 You can run `git reset --soft HEAD~2` to move the HEAD branch back to an older commit (the first commit you want to keep):
 
-image::../images/reset-squash-r2.png[]
+image::images/reset-squash-r2.png[]
 
 And then simply run `git commit` again:
 
-image::../images/reset-squash-r3.png[]
+image::images/reset-squash-r3.png[]
 
 Now you can see that your reachable history, the history you would push, now looks like you had one commit with `file-a.txt` v1, then a second that both modified `file-a.txt` to v2 and added `file-b.txt`.
 
@@ -279,7 +279,7 @@ HEAD will now point to `master`.
 So, in both cases we're moving HEAD to point to commit A, but _how_ we do so is very different.
 `reset` will move the branch HEAD points to, `checkout` moves HEAD itself.
 
-image::../images/reset-checkout.png[]
+image::images/reset-checkout.png[]
 
 ===== With Paths
 

book/07-git-tools/sections/revision-selection.asc

@@ -265,7 +265,7 @@ For example, say you have a commit history that looks like <<double_dot>>.
 
 [[double_dot]]
 .Example history for range selection.
-image::../images/double-dot.png[Example history for range selection.]
+image::images/double-dot.png[Example history for range selection.]
 
 You want to see what is in your experiment branch that hasn’t yet been merged into your master branch.
 You can ask Git to show you a log of just those commits with `master..experiment` – that means ``all commits reachable by experiment that aren’t reachable by master.''

book/07-git-tools/sections/undoing-merges.asc

@@ -8,7 +8,7 @@ Merge commits are no different.
 Let's say you started work on a topic branch, accidentally merged it into `master`, and now your commit history looks like this:
 
 .Accidental merge commit
-image::../images/undomerge-start.png[Accidental merge commit.]
+image::images/undomerge-start.png[Accidental merge commit.]
 
 There are two ways to approach this problem, depending on what your desired outcome is.
 
@@ -18,7 +18,7 @@ If the unwanted merge commit only exists on your local repository, the easiest a
 In most cases, if you follow the errant `git merge` with `git reset --merge ORIG_HEAD`, this will reset the branch pointers so they look like this:
 
 .History after `git reset --merge`
-image::../images/undomerge-reset.png[History after `git reset --merge`.]
+image::images/undomerge-reset.png[History after `git reset --merge`.]
 
 We covered `reset` back in <<_reset>>, so it shouldn't be too hard to figure out what's going on here.
 Here's a quick refresher: `reset --hard` usually goes through three steps:
@@ -52,7 +52,7 @@ In this case, we want to undo all the changes introduced by merging in parent #2
 The history with the revert commit looks like this:
 
 .History after `git revert -m 1`
-image::../images/undomerge-revert.png[History after `git revert -m 1`.]
+image::images/undomerge-revert.png[History after `git revert -m 1`.]
 
 The new commit `^M` has exactly the same contents as `C6`, so starting from here it's as if the merge never happened, except that the now-unmerged commits are still in `HEAD`'s history.
 Git will get confused if you try to merge `topic` into `master` again:
@@ -67,7 +67,7 @@ There's nothing in `topic` that isn't already reachable from `master`.
 What's worse, if you add work to `topic` and merge again, Git will only bring in the changes _since_ the reverted merge:
 
 .History with a bad merge
-image::../images/undomerge-revert2.png[History with a bad merge.]
+image::images/undomerge-revert2.png[History with a bad merge.]
 
 The best way around this is to un-revert the original merge, since now you want to bring in the changes that were reverted out, *then* create a new merge commit:
 
@@ -79,7 +79,7 @@ $ git merge topic
 ----
 
 .History after re-merging a reverted merge
-image::../images/undomerge-revert3.png[History after re-merging a reverted merge.]
+image::images/undomerge-revert3.png[History after re-merging a reverted merge.]
 
 In this example, `M` and `^M` cancel out.
 `^^M` effectively merges in the changes from `C3` and `C4`, and `C8` merges in the changes from `C7`, so now `topic` is fully merged.