From 081e966f52bec20da8581284a76c9c49b55c268e Mon Sep 17 00:00:00 2001 From: Thomas Ackermann Date: Wed, 3 Dec 2014 20:23:02 +0100 Subject: [PATCH 1/2] Use always "SHA-1" instead of "SHA" Signed-off-by: Thomas Ackermann --- book/03-git-branching/sections/rebasing.asc | 2 +- book/06-github/sections/2-contributing.asc | 2 +- book/07-git-tools/sections/advanced-merging.asc | 4 ++-- book/07-git-tools/sections/debugging.asc | 2 +- book/07-git-tools/sections/replace.asc | 12 ++++++------ book/07-git-tools/sections/reset.asc | 4 ++-- book/07-git-tools/sections/revision-selection.asc | 6 +++--- book/07-git-tools/sections/rewriting-history.asc | 4 ++-- book/07-git-tools/sections/submodules.asc | 8 ++++---- book/08-customizing-git/sections/attributes.asc | 6 +++--- book/08-customizing-git/sections/policy.asc | 6 +++--- book/09-git-and-other-scms/sections/client-hg.asc | 2 +- book/09-git-and-other-scms/sections/client-p4.asc | 2 +- book/09-git-and-other-scms/sections/client-svn.asc | 2 +- book/09-git-and-other-scms/sections/client-tfs.asc | 2 +- book/10-git-internals/sections/maintenance.asc | 12 ++++++------ book/10-git-internals/sections/objects.asc | 4 ++-- .../10-git-internals/sections/transfer-protocols.asc | 12 ++++++------ book/C-git-commands/1-git-commands.asc | 4 ++-- 19 files changed, 48 insertions(+), 48 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index b454270d..24d7c47c 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -181,7 +181,7 @@ It's pretty safe to assume that the other developer doesn't want `C4` and `C6` t If you *do* find yourself in a situation like this, Git has some further magic that might help you out. If someone on your team force pushes changes that overwrite work that you've based work on, your challenge is to figure out what is yours and what they've rewritten. -It turns out that in addition to the commit SHA checksum, Git also calculates a checksum that is based just on the patch introduced with the commit. This is called a ``patch-id''. +It turns out that in addition to the commit SHA-1 checksum, Git also calculates a checksum that is based just on the patch introduced with the commit. This is called a ``patch-id''. If you pull down work that was rewritten and rebase it on top of the new commits from your partner, Git can often successfully figure out what is uniquely yours and apply them back on top of the new branch. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 31f0a5c3..38139867 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -276,7 +276,7 @@ Now if Tony goes back and closes out the original Pull Request, we can see that .Cross references rendered in a Pull Request. image::images/mentions-03-closed.png[PR closed] -In addition to issue numbers, you can also reference a specific commit by SHA. You have to specify a full 40 character SHA, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues. +In addition to issue numbers, you can also reference a specific commit by SHA-1. You have to specify a full 40 character SHA-1, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues. ==== Markdown diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index a5e4cbaa..2303c1a1 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -156,7 +156,7 @@ $ git show :2:hello.rb > hello.ours.rb $ git show :3:hello.rb > hello.theirs.rb ---- -If you want to get a little more hard core, you can also use the `ls-files -u` plumbing command to get the actual SHAs of the Git blobs for each of these files. +If you want to get a little more hard core, you can also use the `ls-files -u` plumbing command to get the actual SHA-1s of the Git blobs for each of these files. [source,console] ---- @@ -166,7 +166,7 @@ $ git ls-files -u 100755 e85207e04dfdd5eb0a1e9febbc67fd837c44a1cd 3 hello.rb ---- -The `:1:hello.rb` is just a shorthand for looking up that blob SHA. +The `:1:hello.rb` is just a shorthand for looking up that blob SHA-1. Now that we have the content of all three stages in our working directory, we can manually fix up theirs to fix the whitespace issue and re-merge the file with the little-known `git merge-file` command which does just that. diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 775389c2..bf65ddf8 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -32,7 +32,7 @@ The next two fields are values extracted from that commit–the author name and After that come the line number and the content of the file. Also note the `^4832fe2` commit lines, which designate that those lines were in this file’s original commit. That commit is when this file was first added to this project, and those lines have been unchanged since. -This is a tad confusing, because now you’ve seen at least three different ways that Git uses the `^` to modify a commit SHA, but that is what it means here. +This is a tad confusing, because now you’ve seen at least three different ways that Git uses the `^` to modify a commit SHA-1, but that is what it means here. Another cool thing about Git is that it doesn’t track file renames explicitly. It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index e0ef7984..3d1e1a21 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -5,9 +5,9 @@ Git's objects are unchangeable, but it does provide an interesting way to preten The `replace` command lets you specify an object in Git and say "every time you see this, pretend it's this other thing". This is most commonly useful for replacing one commit in your history with another one. -For example, let's say you have a huge code history and want to split your repository into one short history for new developers and one much longer and larger history for people interested in data mining. You can graft one history onto the other by `replace`ing the earliest commit in the new line with the latest commit on the older one. This is nice because it means that you don't actually have to rewrite every commit in the new history, as you would normally have to do to join them together (because the parentage effects the SHAs). +For example, let's say you have a huge code history and want to split your repository into one short history for new developers and one much longer and larger history for people interested in data mining. You can graft one history onto the other by `replace`ing the earliest commit in the new line with the latest commit on the older one. This is nice because it means that you don't actually have to rewrite every commit in the new history, as you would normally have to do to join them together (because the parentage effects the SHA-1s). -Let's try this out. Let's take an existing repository, split it into two repositories, one recent and one historical, and then we'll see how we can recombine them without modifying the recent repositories SHA values via `replace`. +Let's try this out. Let's take an existing repository, split it into two repositories, one recent and one historical, and then we'll see how we can recombine them without modifying the recent repositories SHA-1 values via `replace`. We'll use a simple repository with five simple commits: @@ -70,7 +70,7 @@ c1822cf first commit It's useful in this case to create a base commit that has instructions on how to expand the history, so other developers know what to do if they hit the first commit in the truncated history and need more. So, what we're going to do is create an initial commit object as our base point with instructions, then rebase the remaining commits (four and five) on top of it. -To do that, we need to choose a point to split at, which for us is the third commit, which is `9c68fdc` in SHA-speak. So, our base commit will be based off of that tree. We can create our base commit using the `commit-tree` command, which just takes a tree and will give us a brand new, parentless commit object SHA back. +To do that, we need to choose a point to split at, which for us is the third commit, which is `9c68fdc` in SHA-speak. So, our base commit will be based off of that tree. We can create our base commit using the `commit-tree` command, which just takes a tree and will give us a brand new, parentless commit object SHA-1 back. [source,console] ---- @@ -85,7 +85,7 @@ The `commit-tree` command is one of a set of commands that are commonly referred 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`): +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-1 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`): [source,console] ---- @@ -153,11 +153,11 @@ e146b5f fifth commit 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. +Cool, right? Without having to change all the SHA-1s 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[] -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: +Interestingly, it still shows `81a708d` as the SHA-1, 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: [source,console] ---- diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 6ff75ac5..acb06803 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -29,7 +29,7 @@ That means HEAD will be the parent of the next commit that is created. It's generally simplest to think of HEAD as the snapshot of *your last commit*. In fact, it's pretty easy to see what that snapshot looks like. -Here is an example of getting the actual directory listing and SHA checksums for each file in the HEAD snapshot: +Here is an example of getting the actual directory listing and SHA-1 checksums for each file in the HEAD snapshot: [source,console] ---- @@ -204,7 +204,7 @@ This actually sort of makes sense – HEAD is just a pointer, and you can't poin But the Index and Working directory _can_ be partially updated, so reset proceeds with steps 2 and 3. So, assume we run `git reset file.txt`. -This form (since you did not specify a commit SHA or branch, and you didn't specify `--soft` or `--hard`) is shorthand for `git reset --mixed HEAD file.txt`, which will: +This form (since you did not specify a commit SHA-1 or branch, and you didn't specify `--soft` or `--hard`) is shorthand for `git reset --mixed HEAD file.txt`, which will: 1. Move the branch HEAD points to _(skipped)_ 2. Make the Index look like HEAD _(stop here)_ diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index b21b1b84..8667b788 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -9,7 +9,7 @@ They aren’t necessarily obvious but are helpful to know. You can obviously refer to a commit by the SHA-1 hash that it’s given, but there are more human-friendly ways to refer to commits as well. This section outlines the various ways you can refer to a single commit. -==== Short SHA +==== Short SHA-1 Git is smart enough to figure out what commit you meant to type if you provide the first few characters, as long as your partial SHA-1 is at least four characters long and unambiguous – that is, only one object in the current repository begins with that partial SHA-1. @@ -60,7 +60,7 @@ a11bef0 first commit Generally, eight to ten characters are more than enough to be unique within a project. -As an example, the Linux kernel, which is a pretty large project with over 450k commits and 3.6 million objects, has no two objects whose SHAs overlap more than the first 11 characters. +As an example, the Linux kernel, which is a pretty large project with over 450k commits and 3.6 million objects, has no two objects whose SHA-1s overlap more than the first 11 characters. [NOTE] .A SHORT NOTE ABOUT SHA-1 @@ -95,7 +95,7 @@ $ git show ca82a6dff817ec66f44342007202690a93763949 $ git show topic1 ---- -If you want to see which specific SHA a branch points to, or if you want to see what any of these examples boils down to in terms of SHAs, you can use a Git plumbing tool called `rev-parse`. +If you want to see which specific SHA-1 a branch points to, or if you want to see what any of these examples boils down to in terms of SHA-1s, you can use a Git plumbing tool called `rev-parse`. You can see <<_git_internals>> for more information about plumbing tools; basically, `rev-parse` exists for lower-level operations and isn’t designed to be used in day-to-day operations. However, it can be helpful sometimes when you need to see what’s really going on. Here you can run `rev-parse` on your branch. diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 9e28a8ac..2e560f1b 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -258,7 +258,7 @@ $ git log -4 --pretty=format:"%h %s" f3cc40e changed my name a bit ---- -Once again, this changes the SHAs of all the commits in your list, so make sure no commit shows up in that list that you’ve already pushed to a shared repository. +Once again, this changes the SHA-1s of all the commits in your list, so make sure no commit shows up in that list that you’ve already pushed to a shared repository. ==== The Nuclear Option: filter-branch @@ -326,4 +326,4 @@ $ git filter-branch --commit-filter ' ---- This goes through and rewrites every commit to have your new address. -Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address. +Because commits contain the SHA-1 values of their parents, this command changes every commit SHA-1 in your history, not just those that have the matching e-mail address. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 4b190489..a345d904 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -541,7 +541,7 @@ Automatic merge failed; fix conflicts and then commit the result. So basically what has happened here is that Git has figured out that the two branches record points in the submodule's history that are divergent and need to be merged. It explains it as ``merge following commits not found'', which is confusing but we'll explain why that is in a bit. -To solve the problem, you need to figure out what state the submodule should be in. Strangely, Git doesn't really give you much information to help out here, not even the SHAs of the commits of both sides of the history. Fortunately, it's simple to figure out. If you run `git diff` you can get the SHAs of the commits recorded in both branches you were trying to merge. +To solve the problem, you need to figure out what state the submodule should be in. Strangely, Git doesn't really give you much information to help out here, not even the SHA-1s of the commits of both sides of the history. Fortunately, it's simple to figure out. If you run `git diff` you can get the SHA-1s of the commits recorded in both branches you were trying to merge. [source,console] ---- @@ -554,9 +554,9 @@ index eb41d76,c771610..0000000 So, in this case, `eb41d76` is the commit in our submodule that *we* had and `c771610` is the commit that upstream had. If we go into our submodule directory, it should already be on `eb41d76` as the merge would not have touched it. If for whatever reason it's not, you can simply create and checkout a branch pointing to it. -What is important is the SHA of the commit from the other side. This is what you'll have to merge in and resolve. You can either just try the merge with the SHA directly, or you can create a branch for it and then try to merge that in. We would suggest the latter, even if only to make a nicer merge commit message. +What is important is the SHA-1 of the commit from the other side. This is what you'll have to merge in and resolve. You can either just try the merge with the SHA-1 directly, or you can create a branch for it and then try to merge that in. We would suggest the latter, even if only to make a nicer merge commit message. -So, we will go into our submodule directory, create a branch based on that second SHA from `git diff` and manually merge. +So, we will go into our submodule directory, create a branch based on that second SHA-1 from `git diff` and manually merge. [source,console] ---- @@ -601,7 +601,7 @@ $ git commit -m "Merge Tom's Changes" <5> <1> First we resolve the conflict <2> Then we go back to the main project directory -<3> We can check the SHAs again +<3> We can check the SHA-1s again <4> Resolve the conflicted submodule entry <5> Commit our merge diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index ec7fdd64..2c4f71ed 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -155,7 +155,7 @@ Git attributes offers you two ways to do this. First, you can inject the SHA-1 checksum of a blob into an `$Id$` field in the file automatically. If you set this attribute on a file or set of files, then the next time you check out that branch, Git will replace that field with the SHA-1 of the blob. -It's important to notice that it isn't the SHA of the commit, but of the blob itself: +It's important to notice that it isn't the SHA-1 of the commit, but of the blob itself: [source,console] ---- @@ -163,7 +163,7 @@ $ echo '*.txt ident' >> .gitattributes $ echo '$Id$' > test.txt ---- -The next time you check out this file, Git injects the SHA of the blob: +The next time you check out this file, Git injects the SHA-1 of the blob: [source,console] ---- @@ -174,7 +174,7 @@ $Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $ ---- However, that result is of limited use. -If you've used keyword substitution in CVS or Subversion, you can include a datestamp – the SHA isn't all that helpful, because it's fairly random and you can't tell if one SHA is older or newer than another just by looking at them. +If you've used keyword substitution in CVS or Subversion, you can include a datestamp – the SHA-1 isn't all that helpful, because it's fairly random and you can't tell if one SHA-1 is older or newer than another just by looking at them. It turns out that you can write your own filters for doing substitutions in files on commit/checkout. These are called ``clean'' and ``smudge'' filters. diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index bbb57ab8..ed488d5a 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -46,7 +46,7 @@ You must look at each commit being pushed up, see if that string is in the commi You can get a list of the SHA-1 values of all the commits that are being pushed by taking the `$newrev` and `$oldrev` values and passing them to a Git plumbing command called `git rev-list`. This is basically the `git log` command, but by default it prints out only the SHA-1 values and no other information. -So, to get a list of all the commit SHAs introduced between one commit SHA and another, you can run something like this: +So, to get a list of all the commit SHA-1s introduced between one commit SHA-1 and another, you can run something like this: [source,console] ---- @@ -58,7 +58,7 @@ dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a 17716ec0f1ff5c77eff40b7fe912f9f6cfd0e475 ---- -You can take that output, loop through each of those commit SHAs, grab the message for it, and test that message against a regular expression that looks for a pattern. +You can take that output, loop through each of those commit SHA-1s, grab the message for it, and test that message against a regular expression that looks for a pattern. You have to figure out how to get the commit message from each of these commits to test. To get the raw commit data, you can use another plumbing command called `git cat-file`. @@ -436,7 +436,7 @@ This script uses a syntax that wasn't covered in the Revision Selection section ---- The `SHA^@` syntax resolves to all the parents of that commit. -You're looking for any commit that is reachable from the last commit on the remote and that isn't reachable from any parent of any of the SHAs you're trying to push up – meaning it's a fast-forward. +You're looking for any commit that is reachable from the last commit on the remote and that isn't reachable from any parent of any of the SHA-1s you're trying to push up – meaning it's a fast-forward. The main drawback to this approach is that it can be very slow and is often unnecessary – if you don't try to force the push with `-f`, the server will warn you and not accept the push. However, it's an interesting exercise and can in theory help you avoid a rebase that you might later have to go back and fix. diff --git a/book/09-git-and-other-scms/sections/client-hg.asc b/book/09-git-and-other-scms/sections/client-hg.asc index bdf8ca0b..984f3889 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -93,7 +93,7 @@ $ tree .git/refs Git-remote-hg is trying to make things more idiomatically Git-esque, but under the hood it's managing the conceptual mapping between two slightly different systems. The `refs/hg` directory is where the actual remote refs are stored. -For example, the `refs/hg/origin/branches/default` is a Git ref file that contains the SHA starting with ``ac7955c'', which is the commit that `master` points to. +For example, the `refs/hg/origin/branches/default` is a Git ref file that contains the SHA-1 starting with ``ac7955c'', which is the commit that `master` points to. So the `refs/hg` directory is kind of like a fake `refs/remotes/origin`, but it has the added distinction between bookmarks and branches. The `notes/hg` file is the starting point for how git-remote-hg maps Git commit hashes to Mercurial changeset IDs. diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index 8dc45b12..83e5393b 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -521,7 +521,7 @@ $ git log --oneline --all --graph --decorate The result is as though we just did a `git push`, which is the closest analogy to what actually did happen. Note that during this process every Git commit is turned into a Perforce changeset; if you want to squash them down into a single changeset, you can do that with an interactive rebase before running `git p4 submit`. -Also note that the SHA hashes of all the commits that were submitted as changesets have changed; this is because git-p4 adds a line to the end of each commit it converts: +Also note that the SHA-1 hashes of all the commits that were submitted as changesets have changed; this is because git-p4 adds a line to the end of each commit it converts: [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 e1bc02f1..ee33f06c 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -206,7 +206,7 @@ Date: Thu Jul 24 03:08:36 2014 +0000 git-svn-id: file:///tmp/test-svn/trunk@77 0b684db3-b064-4277-89d1-21af03df0a68 ---- -Notice that the SHA checksum that originally started with `4af61fd` when you committed now begins with `95e0222`. +Notice that the SHA-1 checksum that originally started with `4af61fd` when you committed now begins with `95e0222`. If you want to push to both a Git server and a Subversion server, you have to push (`dcommit`) to the Subversion server first, because that action changes your commit data. ===== Pulling in New Changes diff --git a/book/09-git-and-other-scms/sections/client-tfs.asc b/book/09-git-and-other-scms/sections/client-tfs.asc index 67a600b3..8c1c8832 100644 --- a/book/09-git-and-other-scms/sections/client-tfs.asc +++ b/book/09-git-and-other-scms/sections/client-tfs.asc @@ -264,7 +264,7 @@ There are a couple of other considerations you'll want to keep in mind: * There is no branching. Git-tf can only create Git repositories from one TFVC branch at a time. * Collaborate using either TFVC or Git, but not both. - Different git-tf clones of the same TFVC repository may have different commit SHA hashes, which will cause no end of headaches. + Different git-tf clones of the same TFVC repository may have different commit SHA-1 hashes, which will cause no end of headaches. * If your team's workflow includes collaborating in Git and syncing periodically with TFVC, only connect to TFVC with one of the Git repositories. diff --git a/book/10-git-internals/sections/maintenance.asc b/book/10-git-internals/sections/maintenance.asc index ecf8f202..dd632036 100644 --- a/book/10-git-internals/sections/maintenance.asc +++ b/book/10-git-internals/sections/maintenance.asc @@ -49,7 +49,7 @@ cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0 ---- If you update a reference, Git doesn't edit this file but instead writes a new file to `refs/heads`. -To get the appropriate SHA for a given reference, Git checks for that reference in the `refs` directory and then checks the `packed-refs` file as a fallback. +To get the appropriate SHA-1 for a given reference, Git checks for that reference in the `refs` directory and then checks the `packed-refs` file as a fallback. However, if you can't find a reference in the `refs` directory, it's probably in your `packed-refs` file. Notice the last line of the file, which begins with a `^`. @@ -88,13 +88,13 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit ---- You've effectively lost the top two commits – you have no branch from which those commits are reachable. -You need to find the latest commit SHA and then add a branch that points to it. -The trick is finding that latest commit SHA – it's not like you've memorized it, right? +You need to find the latest commit SHA-1 and then add a branch that points to it. +The trick is finding that latest commit SHA-1 – it's not like you've memorized it, right? Often, the quickest way is to use a tool called `git reflog`. As you're working, Git silently records what your HEAD is every time you change it. Each time you commit or change branches, the reflog is updated. -The reflog is also updated by the `git update-ref` command, which is another reason to use it instead of just writing the SHA value to your ref files, as we covered in <<_git_refs>>. +The reflog is also updated by the `git update-ref` command, which is another reason to use it instead of just writing the SHA-1 value to your ref files, as we covered in <<_git_refs>>. You can see where you've been at any time by running `git reflog`: [source,console] @@ -169,7 +169,7 @@ dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293 ---- In this case, you can see your missing commit after the string ``dangling commit''. -You can recover it the same way, by adding a branch that points to that SHA. +You can recover it the same way, by adding a branch that points to that SHA-1. [[_removing_objects]] ==== Removing Objects @@ -263,7 +263,7 @@ dadf7258d699da2c8d89b09ef6670edb7d5f91b4 commit 229 159 12 The big object is at the bottom: 5MB. To find out what file it is, you'll use the `rev-list` command, which you used briefly in <<_enforcing_commit_message_format>>. -If you pass `--objects` to `rev-list`, it lists all the commit SHAs and also the blob SHAs with the file paths associated with them. +If you pass `--objects` to `rev-list`, it lists all the commit SHA-1s and also the blob SHA-1s with the file paths associated with them. You can use this to find your blob's name: [source,console] diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index b4c1dcc0..84d594c4 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -44,7 +44,7 @@ $ find .git/objects -type f You can see a file in the `objects` directory. This is how Git stores the content initially – as a single file per piece of content, named with the SHA-1 checksum of the content and its header. -The subdirectory is named with the first 2 characters of the SHA, and the filename is the remaining 38 characters. +The subdirectory is named with the first 2 characters of the SHA-1, and the filename is the remaining 38 characters. You can pull the content back out of Git with the `cat-file` command. This command is sort of a Swiss army knife for inspecting Git objects. @@ -204,7 +204,7 @@ $ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341 100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt ---- -Notice that this tree has both file entries and also that the test.txt SHA is the ``version 2'' SHA from earlier (`1f7a7a`). +Notice that this tree has both file entries and also that the test.txt SHA-1 is the ``version 2'' SHA-1 from earlier (`1f7a7a`). Just for fun, you'll add the first tree as a subdirectory into this one. You can read trees into your staging area by calling `read-tree`. In this case, you can read an existing tree into your staging area as a subtree by using the `--prefix` option to `read-tree`: diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index e56e2906..7db265f5 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -31,7 +31,7 @@ This file is written by the `update-server-info` command, which is why you need ca82a6dff817ec66f44342007202690a93763949 refs/heads/master ---- -Now you have a list of the remote references and SHAs. +Now you have a list of the remote references and SHA-1s. Next, you look for what the HEAD reference is so you know what to check out when you're finished: [source] @@ -110,7 +110,7 @@ This is also useful if you have multiple packfiles on the server, so you can see (4k of binary data) ---- -Now that you have the packfile index, you can see if your object is in it – because the index lists the SHAs of the objects contained in the packfile and the offsets to those objects. +Now that you have the packfile index, you can see if your object is in it – because the index lists the SHA-1s of the objects contained in the packfile and the offsets to those objects. Your object is there, so go ahead and get the whole packfile: [source] @@ -151,7 +151,7 @@ $ ssh -x git@server "git-receive-pack 'simplegit-progit.git'" 0000 ---- -The `git-receive-pack` command immediately responds with one line for each reference it currently has – in this case, just the `master` branch and its SHA. +The `git-receive-pack` command immediately responds with one line for each reference it currently has – in this case, just the `master` branch and its SHA-1. The first line also has a list of the server's capabilities (here, `report-status`, `delete-refs`, and some others, including the client identifier). Each line starts with a 4-character hex value specifying how long the rest of the line is. @@ -172,7 +172,7 @@ For instance, if you're updating the `master` branch and adding an `experiment` 0000 ---- -Git sends a line for each reference you're updating with the line's length, the old SHA, the new SHA, and the reference that is being updated. +Git sends a line for each reference you're updating with the line's length, the old SHA-1, the new SHA-1, and the reference that is being updated. The first line also has the client's capabilities. The SHA-1 value of all '0's means that nothing was there before – because you're adding the experiment reference. If you were deleting a reference, you would see the opposite: all '0's on the right side. @@ -241,8 +241,8 @@ After `fetch-pack` connects, `upload-pack` sends back something like this: This is very similar to what `receive-pack` responds with, but the capabilities are different. In addition, it sends back what HEAD points to (`symref=HEAD:refs/heads/master`) so the client knows what to check out if this is a clone. -At this point, the `fetch-pack` process looks at what objects it has and responds with the objects that it needs by sending ``want'' and then the SHA it wants. -It sends all the objects it already has with ``have'' and then the SHA. +At this point, the `fetch-pack` process looks at what objects it has and responds with the objects that it needs by sending ``want'' and then the SHA-1 it wants. +It sends all the objects it already has with ``have'' and then the SHA-1. At the end of this list, it writes ``done'' to initiate the `upload-pack` process to begin sending the packfile of the data it needs: [source] diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc index 2e1696a3..30e75f5f 100644 --- a/book/C-git-commands/1-git-commands.asc +++ b/book/C-git-commands/1-git-commands.asc @@ -323,7 +323,7 @@ We showed how to use it to create a nice changelog in <<_the_shortlog>>. ==== git describe -The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change. It's a way to get a description of a commit that is as unambiguous as a commit SHA but more understandable. +The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change. It's a way to get a description of a commit that is as unambiguous as a commit SHA-1 but more understandable. We use `git describe` in <<_build_number>> and <<_preparing_release>> to get a string to name our release file after. @@ -473,6 +473,6 @@ The first one we encounter is `ls-remote` in <<_pr_refs>> which we use to look a We use `ls-files` in <<_manual_remerge>>, <<_rerere>> and <<_the_index>> to take a more raw look at what your staging area looks like. -We also mention `rev-parse` in <<_branch_references>> to take just about any string and turn it into an object SHA. +We also mention `rev-parse` in <<_branch_references>> to take just about any string and turn it into an object SHA-1. However, most of the low level plumbing commands we cover are in <<_git_internals>>, which is more or less what the chapter is focused on. We tried to avoid use of them throughout most of the rest of the book. From e63b0fc2b8e5e5a0c7627fdeae38d4b2988fe04b Mon Sep 17 00:00:00 2001 From: Thomas Ackermann Date: Wed, 3 Dec 2014 20:32:54 +0100 Subject: [PATCH 2/2] Remove dangling full stop Signed-off-by: Thomas Ackermann --- book/08-customizing-git/sections/policy.asc | 1 - 1 file changed, 1 deletion(-) diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index ed488d5a..14ca5549 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -432,7 +432,6 @@ This script uses a syntax that wasn't covered in the Revision Selection section [source,ruby] ---- `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}` -. ---- The `SHA^@` syntax resolves to all the parents of that commit.