From f3a9f26f1bc6f10e81c7d9c49444410c40584766 Mon Sep 17 00:00:00 2001 From: "Robert P. J. Day" Date: Sun, 8 Oct 2017 10:08:15 -0400 Subject: [PATCH 1/2] Standardize on , not or for examples I'm a big believer in consistency. --- book/02-git-basics/sections/remotes.asc | 6 +++--- book/03-git-branching/sections/remote-branches.asc | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 56d3e0d32..d3bce2bf2 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -104,7 +104,7 @@ As you just saw, to get data from your remote projects, you can run:(((git comma [source,console] ---- -$ git fetch +$ git fetch ---- The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. @@ -123,7 +123,7 @@ Running `git pull` generally fetches data from the server you originally cloned ==== Pushing to Your Remotes When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push `.(((git commands, push))) +The command for this is simple: `git push `.(((git commands, push))) If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: [source,console] @@ -139,7 +139,7 @@ See <<_git_branching>> for more detailed information on how to push to remote se [[_inspecting_remote]] ==== Inspecting a Remote -If you want to see more information about a particular remote, you can use the `git remote show ` command.(((git commands, remote))) +If you want to see more information about a particular remote, you can use the `git remote show ` command.(((git commands, remote))) If you run this command with a particular shortname, such as `origin`, you get something like this: [source,console] diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 10ae22ec6..5465935fc 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -136,7 +136,7 @@ If you're on a tracking branch and type `git pull`, Git automatically knows whic When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. However, you can set up other tracking branches if you wish – ones that track branches on other remotes, or don't track the `master` branch. -The simple case is the example you just saw, running `git checkout -b /`. +The simple case is the example you just saw, running `git checkout -b /`. This is a common enough operation that Git provides the `--track` shorthand: [source,console] From b1e573dda0708c7ee4ea4e5d6d41c956df83aa20 Mon Sep 17 00:00:00 2001 From: "Robert P. J. Day" Date: Sun, 8 Oct 2017 10:19:59 -0400 Subject: [PATCH 2/2] Might as well somewhat standardize on references to branch names as well. --- book/02-git-basics/sections/remotes.asc | 2 +- book/02-git-basics/sections/tagging.asc | 2 +- book/07-git-tools/sections/stashing-cleaning.asc | 2 +- book/09-git-and-other-scms/sections/client-svn.asc | 2 +- book/10-git-internals/sections/refs.asc | 4 ++-- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index d3bce2bf2..4913ab2ca 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -123,7 +123,7 @@ Running `git pull` generally fetches data from the server you originally cloned ==== Pushing to Your Remotes When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push `.(((git commands, push))) +The command for this is simple: `git push `.(((git commands, push))) If you want to push your master branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: [source,console] diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 1550af938..3ee8ee9e8 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -225,7 +225,7 @@ state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: - git checkout -b + git checkout -b HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 96903e15f..005b94e9b 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -189,7 +189,7 @@ Saved working directory and index state WIP on master: 1b65b17 added the index f If you stash some work, leave it there for a while, and continue on the branch from which you stashed the work, you may have a problem reapplying the work. If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to try to resolve it. -If you want an easier way to test the stashed changes again, you can run `git stash branch `, which creates a new branch for you with the given `branch-name`, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully: +If you want an easier way to test the stashed changes again, you can run `git stash branch `, which creates a new branch for you with your selected branch name, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully: [source,console] ---- diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index 46bc52f7b..9a3f28c80 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -341,7 +341,7 @@ However, you can create and commit to branches in Subversion using `git svn`. ===== Creating a New SVN Branch -To create a new branch in Subversion, you run `git svn branch [branchname]`: +To create a new branch in Subversion, you run `git svn branch [new-branch]`: [source,console] ---- diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index d87c541c0..3f758175a 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -63,12 +63,12 @@ Now, your Git database conceptually looks something like this: .Git directory objects with branch head references included. image::images/data-model-4.png[Git directory objects with branch head references included.] -When you run commands like `git branch `, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create. +When you run commands like `git branch `, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create. [[_the_head]] ==== The HEAD -The question now is, when you run `git branch `, how does Git know the SHA-1 of the last commit? +The question now is, when you run `git branch `, how does Git know the SHA-1 of the last commit? The answer is the HEAD file. The HEAD file is a symbolic reference to the branch you're currently on.