From a1bba67cb098c268d79c59429029fd21ac46c789 Mon Sep 17 00:00:00 2001 From: ajax333221 Date: Tue, 8 Jan 2019 22:46:36 -0600 Subject: [PATCH] single-quote normalization --- book/04-git-server/sections/protocols.asc | 4 +- book/04-git-server/sections/smart-http.asc | 2 +- book/06-github/sections/2-contributing.asc | 4 +- book/07-git-tools/sections/debugging.asc | 20 ++++----- .../sections/interactive-staging.asc | 16 +++---- .../sections/revision-selection.asc | 42 +++++++++--------- .../sections/rewriting-history.asc | 44 +++++++++---------- book/07-git-tools/sections/signing.asc | 4 +- .../sections/stashing-cleaning.asc | 20 ++++----- book/07-git-tools/sections/submodules.asc | 28 ++++++------ book/07-git-tools/sections/subtree-merges.asc | 4 +- .../sections/import-bzr.asc | 2 +- book/10-git-internals/sections/refs.asc | 2 +- book/introduction.asc | 18 ++++---- ch07-git-tools.asc | 12 ++--- 15 files changed, 111 insertions(+), 111 deletions(-) diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 8c10ca84b..946cf5ae3 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -175,7 +175,7 @@ Last, like the HTTPS, Git and Local protocols, SSH is efficient, making the data The negative aspect of SSH is that it doesn't support anonymous access to your Git repository. If you're using SSH, people _must_ have SSH access to your machine, even in a read-only capacity, which doesn't make SSH conducive to open source projects for which people might simply want to clone your repository to examine it. If you're using it only within your corporate network, SSH may be the only protocol you need to deal with. -If you want to allow anonymous read-only access to your projects and also want to use SSH, you’ll have to set up SSH for you to push over but something else for others to fetch from. +If you want to allow anonymous read-only access to your projects and also want to use SSH, you'll have to set up SSH for you to push over but something else for others to fetch from. ==== The Git Protocol @@ -191,7 +191,7 @@ Suffice it to say that this is rare. ===== The Pros The Git protocol is often the fastest network transfer protocol available. -If you’re serving a lot of traffic for a public project or serving a very large project that doesn't require user authentication for read access, it’s likely that you'll want to set up a Git daemon to serve your project. +If you're serving a lot of traffic for a public project or serving a very large project that doesn't require user authentication for read access, it's likely that you'll want to set up a Git daemon to serve your project. It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead. ===== The Cons diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 43956dda8..973a72770 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -18,7 +18,7 @@ $ a2enmod cgi alias env This also enables the `mod_cgi`, `mod_alias`, and `mod_env` modules, which are all needed for this to work properly. -You’ll also need to set the Unix user group of the `/srv/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: +You'll also need to set the Unix user group of the `/srv/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: [source,console] ---- diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 1372cdc91..5ee613388 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -5,7 +5,7 @@ Now that our account is set up, let's walk through some details that could be us ==== Forking Projects (((forking))) -If you want to contribute to an existing project to which you don’t have push access, you can ``fork'' the project. +If you want to contribute to an existing project to which you don't have push access, you can ``fork'' the project. When you ``fork'' a project, GitHub will make a copy of the project that is entirely yours; it lives in your namespace, and you can push to it. [NOTE] @@ -14,7 +14,7 @@ Historically, the term ``fork'' has been somewhat negative in context, meaning t In GitHub, a ``fork'' is simply the same project in your own namespace, allowing you to make changes to a project publicly as a way to contribute in a more open manner. ==== -This way, projects don’t have to worry about adding users as collaborators to give them push access. +This way, projects don't have to worry about adding users as collaborators to give them push access. People can fork a project, push to it, and contribute their changes back to the original repository by creating what's called a Pull Request, which we'll cover next. This opens up a discussion thread with code review, and the owner and the contributor can then communicate about the change until the owner is happy with it, at which point the owner can merge it in. diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 093de5713..018b50541 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -35,12 +35,12 @@ Notice that the first field is the partial SHA-1 of the commit that last modifie The next two fields are values extracted from that commit -- the author name and the authored date of that commit -- so you can easily see who modified that line and when. After that come the line number and the content of the file. Also note the `^1da177e4c3f4` commit lines, where the `^` prefix designates lines that were introduced in the repository's initial commit and have remained unchanged ever 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-1, 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. +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. One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. -If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. +If you pass `-C` to `git blame`, Git analyzes the file you're annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. For example, say you are refactoring a file named `GITServerHandler.m` into multiple files, one of which is `GITPackUpload.m`. By blaming `GITPackUpload.m` with the `-C` option, you can see where sections of the code originally came from: @@ -70,13 +70,13 @@ Git tells you the original commit where you wrote those lines, even if it was in ==== Binary Search Annotating a file helps if you know where the issue is to begin with. -If you don’t know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you’ll likely turn to `git bisect` for help. +If you don't know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you'll likely turn to `git bisect` for help. The `bisect` command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue. -Let’s say you just pushed out a release of your code to a production environment, you’re getting bug reports about something that wasn’t happening in your development environment, and you can’t imagine why the code is doing that. -You go back to your code, and it turns out you can reproduce the issue, but you can’t figure out what is going wrong. +Let's say you just pushed out a release of your code to a production environment, you're getting bug reports about something that wasn't happening in your development environment, and you can't imagine why the code is doing that. +You go back to your code, and it turns out you can reproduce the issue, but you can't figure out what is going wrong. You can _bisect_ the code to find out. -First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you’re on is broken. +First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you're on is broken. Then, you must tell bisect when the last known good state was, using `git bisect good `: [source,console] @@ -90,7 +90,7 @@ Bisecting: 6 revisions left to test after this Git figured out that about 12 commits came between the commit you marked as the last good commit (v1.0) and the current bad version, and it checked out the middle one for you. At this point, you can run your test to see if the issue exists as of this commit. -If it does, then it was introduced sometime before this middle commit; if it doesn’t, then the problem was introduced sometime after the middle commit. +If it does, then it was introduced sometime before this middle commit; if it doesn't, then the problem was introduced sometime after the middle commit. It turns out there is no issue here, and you tell Git that by typing `git bisect good` and continue your journey: [source,console] @@ -100,7 +100,7 @@ Bisecting: 3 revisions left to test after this [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing ---- -Now you’re on another commit, halfway between the one you just tested and your bad commit. +Now you're on another commit, halfway between the one you just tested and your bad commit. You run your test again and find that this commit is broken, so you tell Git that with `git bisect bad`: [source,console] @@ -127,7 +127,7 @@ Date: Tue Jan 27 14:48:32 2009 -0800 f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config ---- -When you’re finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you’ll end up in a weird state: +When you're finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you'll end up in a weird state: [source,console] ---- diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index f9ba5edd6..affa704b2 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -1,7 +1,7 @@ [[_interactive_staging]] === Interactive Staging -In this section, you’ll look at a few interactive Git commands that can help you craft your commits to include only certain combinations and parts of files. +In this section, you'll look at a few interactive Git commands that can help you craft your commits to include only certain combinations and parts of files. These tools are helpful if you modify a number of files extensively, then decide that you want those changes to be partitioned into several focused commits rather than one big messy commit. This way, you can make sure your commits are logically separate changesets and can be reviewed easily by the developers working with you. @@ -22,7 +22,7 @@ What now> ---- You can see that this command shows you a much different view of your staging area than you're probably used to -- basically, the same information you get with `git status` but a bit more succinct and informative. -It lists the changes you’ve staged on the left and unstaged changes on the right. +It lists the changes you've staged on the left and unstaged changes on the right. After this comes a ``Commands'' section, which allows you to do a number of things like staging and unstaging files, staging parts of files, adding untracked files, and displaying diffs of what has been staged. @@ -92,7 +92,7 @@ Revert>> [enter] reverted one path ---- -Looking at your Git status again, you can see that you’ve unstaged the `TODO` file: +Looking at your Git status again, you can see that you've unstaged the `TODO` file: [source,console] ---- @@ -106,7 +106,7 @@ What now> s 3: unchanged +5/-1 lib/simplegit.rb ---- -To see the diff of what you’ve staged, you can use the `d` or `6` (for diff) command. +To see the diff of what you've staged, you can use the `d` or `6` (for diff) command. It shows you a list of your staged files, and you can select the ones for which you would like to see the staged diff. This is much like specifying `git diff --cached` on the command line: @@ -137,7 +137,7 @@ With these basic commands, you can use the interactive add mode to deal with you ==== Staging Patches -It’s also possible for Git to stage certain _parts_ of files and not the rest. +It's also possible for Git to stage certain _parts_ of files and not the rest. For example, if you make two changes to your `simplegit.rb` file and want to stage one of them and not the other, doing so is very easy in Git. From the same interactive prompt explained in the previous section, type `p` or `5` (for patch). Git will ask you which files you would like to partially stage; then, for each section of the selected files, it will display hunks of the file diff and ask if you would like to stage them, one by one: @@ -181,7 +181,7 @@ e - manually edit the current hunk ? - print help ---- -Generally, you’ll type `y` or `n` if you want to stage each hunk, but staging all of them in certain files or skipping a hunk decision until later can be helpful too. +Generally, you'll type `y` or `n` if you want to stage each hunk, but staging all of them in certain files or skipping a hunk decision until later can be helpful too. If you stage one part of the file and leave another part unstaged, your status output will look like this: [source,console] @@ -195,10 +195,10 @@ What now> 1 The status of the `simplegit.rb` file is interesting. It shows you that a couple of lines are staged and a couple are unstaged. -You’ve partially staged this file. +You've partially staged this file. At this point, you can exit the interactive adding script and run `git commit` to commit the partially staged files. -You also don’t need to be in interactive add mode to do the partial-file staging -- you can start the same script by using `git add -p` or `git add --patch` on the command line. +You also don't need to be in interactive add mode to do the partial-file staging -- you can start the same script by using `git add -p` or `git add --patch` on the command line. Furthermore, you can use patch mode for partially resetting files with the `git reset --patch` command, for checking out parts of files with the `git checkout --patch` command and for stashing parts of files with the `git stash save --patch` command. We'll go into more details on each of these as we get to more advanced usages of these commands. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index b5bd1413e..9139265e4 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -2,7 +2,7 @@ === Revision Selection Git allows you to refer to a set of commits or a range of commits in several ways. -They aren’t necessarily obvious but are helpful to know. +They aren't necessarily obvious but are helpful to know. ==== Single Revisions @@ -70,7 +70,7 @@ A lot of people become concerned at some point that they will, by random happens What then? If you do happen to commit an object that hashes to the same SHA-1 value as a previous _different_ object in your repository, Git will see the previous object already in your Git database, assume it was already written and simply reuse it. -If you try to check out that object again at some point, you’ll always get the data of the first object. +If you try to check out that object again at some point, you'll always get the data of the first object. However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. @@ -78,9 +78,9 @@ The number of randomly hashed objects needed to ensure a 50% probability of a si (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80^ is 1.2 x 10^24^ or 1 million billion billion. -That’s 1,200 times the number of grains of sand on the earth. +That's 1,200 times the number of grains of sand on the earth. -Here’s an example to give you an idea of what it would take to get a SHA-1 collision. +Here's an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (6.5 million Git objects) and pushing it into one enormous Git repository, it would take roughly 2 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. Thus, a SHA-1 collision is less likely than every member of your programming team being attacked and killed by wolves in unrelated incidents on the same night. @@ -99,8 +99,8 @@ $ git show topic1 ---- 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 <> 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. +You can see <> 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. [source,console] @@ -112,7 +112,7 @@ ca82a6dff817ec66f44342007202690a93763949 [[_git_reflog]] ==== RefLog Shortnames -One of the things Git does in the background while you’re working away is keep a ``reflog'' -- a log of where your HEAD and branch references have been for the last few months. +One of the things Git does in the background while you're working away is keep a ``reflog'' -- a log of where your HEAD and branch references have been for the last few months. You can see your reflog by using `git reflog`: @@ -146,7 +146,7 @@ $ git show master@{yesterday} ---- That would show you where tip of your `master` branch was yesterday. -This technique only works for data that’s still in your reflog, so you can’t use it to look for commits older than a few months. +This technique only works for data that's still in your reflog, so you can't use it to look for commits older than a few months. To see reflog information formatted like the `git log` output, you can run `git log -g`: @@ -170,8 +170,8 @@ Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' ---- -It’s important to note that reflog information is strictly local -- it’s a log only of what _you've_ done in _your_ repository. -The references won’t be the same on someone else’s copy of the repository; also, right after you initially clone a repository, you'll have an empty reflog, as no activity has occurred yet in your repository. +It's important to note that reflog information is strictly local -- it's a log only of what _you've_ done in _your_ repository. +The references won't be the same on someone else's copy of the repository; also, right after you initially clone a repository, you'll have an empty reflog, as no activity has occurred yet in your repository. Running `git show HEAD@{2.months.ago}` will show you the matching commit only if you cloned the project at least two months ago -- if you cloned it any more recently than that, you'll see only your first local commit. [TIP] @@ -280,21 +280,21 @@ You can also combine these syntaxes -- you can get the second parent of the prev [[_commit_ranges]] ==== Commit Ranges -Now that you can specify individual commits, let’s see how to specify ranges of commits. -This is particularly useful for managing your branches -- if you have a lot of branches, you can use range specifications to answer questions such as, ``What work is on this branch that I haven’t yet merged into my main branch?'' +Now that you can specify individual commits, let's see how to specify ranges of commits. +This is particularly useful for managing your branches -- if you have a lot of branches, you can use range specifications to answer questions such as, ``What work is on this branch that I haven't yet merged into my main branch?'' ===== Double Dot The most common range specification is the double-dot syntax. -This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another. +This basically asks Git to resolve a range of commits that are reachable from one commit but aren't reachable from another. For example, say you have a commit history that looks like <>. [[double_dot]] .Example history for range selection. image::images/double-dot.png[Example history for range selection.] -Say 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 from experiment that aren’t reachable from master.'' +Say 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 from experiment that aren't reachable from master.'' For the sake of brevity and clarity in these examples, the letters of the commit objects from the diagram are used in place of the actual log output in the order that they would display: [source,console] @@ -304,7 +304,7 @@ D C ---- -If, on the other hand, you want to see the opposite -- all commits in `master` that aren’t in `experiment` -- you can reverse the branch names. +If, on the other hand, you want to see the opposite -- all commits in `master` that aren't in `experiment` -- you can reverse the branch names. `experiment..master` shows you everything in `master` not reachable from `experiment`: [source,console] @@ -314,23 +314,23 @@ F E ---- -This is useful if you want to keep the `experiment` branch up to date and preview what you’re about to merge. -Another frequent use of this syntax is to see what you’re about to push to a remote: +This is useful if you want to keep the `experiment` branch up to date and preview what you're about to merge. +Another frequent use of this syntax is to see what you're about to push to a remote: [source,console] ---- $ git log origin/master..HEAD ---- -This command shows you any commits in your current branch that aren’t in the `master` branch on your `origin` remote. +This command shows you any commits in your current branch that aren't in the `master` branch on your `origin` remote. If you run a `git push` and your current branch is tracking `origin/master`, the commits listed by `git log origin/master..HEAD` are the commits that will be transferred to the server. You can also leave off one side of the syntax to have Git assume `HEAD`. For example, you can get the same results as in the previous example by typing `git log origin/master..` -- Git substitutes `HEAD` if one side is missing. ===== Multiple Points -The double-dot syntax is useful as a shorthand, but perhaps you want to specify more than two branches to indicate your revision, such as seeing what commits are in any of several branches that aren’t in the branch you’re currently on. -Git allows you to do this by using either the `^` character or `--not` before any reference from which you don’t want to see reachable commits. +The double-dot syntax is useful as a shorthand, but perhaps you want to specify more than two branches to indicate your revision, such as seeing what commits are in any of several branches that aren't in the branch you're currently on. +Git allows you to do this by using either the `^` character or `--not` before any reference from which you don't want to see reachable commits. Thus, the following three commands are equivalent: [source,console] diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 6f6db755a..e6fdd5fab 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -3,10 +3,10 @@ Many times, when working with Git, you may want to revise your local commit history. One of the great things about Git is that it allows you to make decisions at the last possible moment. -You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with `git stash`, and you can rewrite commits that already happened so they look like they happened in a different way. +You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn't mean to be working on something yet with `git stash`, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely -- all before you share your work with others. -In this section, you’ll see how to accomplish these tasks so that you can make your commit history look the way you want before you share it with others. +In this section, you'll see how to accomplish these tasks so that you can make your commit history look the way you want before you share it with others. [NOTE] ==== @@ -18,8 +18,8 @@ In short, you should avoid pushing your work until you're happy with it and read [[_git_amend]] ==== Changing the Last Commit -Changing your most recent commit is probably the most common rewriting of history that you’ll do. -You’ll often want to do two basic things to your last commit: simply change the commit message, or change the actual content of the commit by adding, removing and modifying files. +Changing your most recent commit is probably the most common rewriting of history that you'll do. +You'll often want to do two basic things to your last commit: simply change the commit message, or change the actual content of the commit by adding, removing and modifying files. If you simply want to modify your last commit message, that's easy: @@ -34,7 +34,7 @@ When you save and close the editor, the editor writes a new commit containing th If, on the other hand, you want to change the actual _content_ of your last commit, the process works basically the same way -- first make the changes you think you forgot, stage those changes, and the subsequent `git commit --amend` _replaces_ that last commit with your new, improved commit. You need to be careful with this technique because amending changes the SHA-1 of the commit. -It’s like a very small rebase -- don’t amend your last commit if you’ve already pushed it. +It's like a very small rebase -- don't amend your last commit if you've already pushed it. [TIP] .An amended commit may (or may not) need an amended commit message @@ -55,13 +55,13 @@ $ git commit --amend --no-edit ==== Changing Multiple Commit Messages To modify a commit that is farther back in your history, you must move to more complex tools. -Git doesn’t have a modify-history tool, but you can use the rebase tool to rebase a series of commits onto the HEAD they were originally based on instead of moving them to another one. +Git doesn't have a modify-history tool, but you can use the rebase tool to rebase a series of commits onto the HEAD they were originally based on instead of moving them to another one. With the interactive rebase tool, you can then stop after each commit you want to modify and change the message, add files, or do whatever you wish. You can run rebase interactively by adding the `-i` option to `git rebase`. You must indicate how far back you want to rewrite commits by telling the command which commit to rebase onto. For example, if you want to change the last three commit messages, or any of the commit messages in that group, you supply as an argument to `git rebase -i` the parent of the last commit you want to edit, which is `HEAD~2^` or `HEAD~3`. -It may be easier to remember the `~3` because you’re trying to edit the last three commits, but keep in mind that you’re actually designating four commits ago, the parent of the last commit you want to edit: +It may be easier to remember the `~3` because you're trying to edit the last three commits, but keep in mind that you're actually designating four commits ago, the parent of the last commit you want to edit: [source,console] ---- @@ -69,7 +69,7 @@ $ git rebase -i HEAD~3 ---- Remember again that this is a rebasing command – every commit included in the range `HEAD~3..HEAD` will be rewritten, whether you change the message or not. -Don’t include any commit you’ve already pushed to a central server – doing so will confuse other developers by providing an alternate version of the same change. +Don't include any commit you've already pushed to a central server – doing so will confuse other developers by providing an alternate version of the same change. Running this command gives you a list of commits in your text editor that looks something like this: @@ -98,7 +98,7 @@ pick a5f4a0d added cat-file # Note that empty commits are commented out ---- -It’s important to note that these commits are listed in the opposite order than you normally see them using the `log` command. +It's important to note that these commits are listed in the opposite order than you normally see them using the `log` command. If you run a `log`, you see something like this: [source,console] @@ -110,9 +110,9 @@ f7f3f6d changed my name a bit ---- Notice the reverse order. -The interactive rebase gives you a script that it’s going to run. +The interactive rebase gives you a script that it's going to run. It will start at the commit you specify on the command line (`HEAD~3`) and replay the changes introduced in each of these commits from top to bottom. -It lists the oldest at the top, rather than the newest, because that’s the first one it will replay. +It lists the oldest at the top, rather than the newest, because that's the first one it will replay. You need to edit the script so that it stops at the commit you want to edit. To do so, change the word `pick' to the word `edit' for each of the commits you want the script to stop after. @@ -135,7 +135,7 @@ You can amend the commit now, with git commit --amend -Once you’re satisfied with your changes, run +Once you're satisfied with your changes, run git rebase --continue ---- @@ -156,9 +156,9 @@ Then, run $ git rebase --continue ---- -This command will apply the other two commits automatically, and then you’re done. +This command will apply the other two commits automatically, and then you're done. If you change pick to edit on more lines, you can repeat these steps for each commit you change to edit. -Each time, Git will stop, let you amend the commit, and continue when you’re finished. +Each time, Git will stop, let you amend the commit, and continue when you're finished. ==== Reordering Commits @@ -186,7 +186,7 @@ You effectively change the order of those commits and remove the ``added cat-fil [[_squashing]] ==== Squashing Commits -It’s also possible to take a series of commits and squash them down into a single commit with the interactive rebasing tool. +It's also possible to take a series of commits and squash them down into a single commit with the interactive rebasing tool. The script puts helpful instructions in the rebase message: [source,console] @@ -255,7 +255,7 @@ pick a5f4a0d added cat-file Then, when the script drops you to the command line, you reset that commit, take the changes that have been reset, and create multiple commits out of them. When you save and exit the editor, Git rewinds to the parent of the first commit in your list, applies the first commit (`f7f3f6d`), applies the second (`310154e`), and drops you to the console. There, you can do a mixed reset of that commit with `git reset HEAD^`, which effectively undoes that commit and leaves the modified files unstaged. -Now you can stage and commit files until you have several commits, and run `git rebase --continue` when you’re done: +Now you can stage and commit files until you have several commits, and run `git rebase --continue` when you're done: [source,console] ---- @@ -278,14 +278,14 @@ $ git log -4 --pretty=format:"%h %s" f3cc40e changed my name a bit ---- -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. +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 There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way – for instance, changing your email address globally or removing a file from every commit. -The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. +The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn't use it unless your project isn't yet public and other people haven't based work off the commits you're about to rewrite. However, it can be very useful. -You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of. +You'll learn a few of the common uses so you can get an idea of some of the things it's capable of. [[_removing_file_every_commit]] ===== Removing a File from Every Commit @@ -307,13 +307,13 @@ The `--tree-filter` option runs the specified command after each checkout of the In this case, you remove a file called `passwords.txt` from every snapshot, whether it exists or not. If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch --tree-filter 'rm -f *~' HEAD`. -You’ll be able to watch Git rewriting trees and commits and then move the branch pointer at the end. -It’s generally a good idea to do this in a testing branch and then hard-reset your master branch after you’ve determined the outcome is what you really want. +You'll be able to watch Git rewriting trees and commits and then move the branch pointer at the end. +It's generally a good idea to do this in a testing branch and then hard-reset your master branch after you've determined the outcome is what you really want. To run `filter-branch` on all your branches, you can pass `--all` to the command. ===== Making a Subdirectory the New Root -Suppose you’ve done an import from another source control system and have subdirectories that make no sense (`trunk`, `tags`, and so on). +Suppose you've done an import from another source control system and have subdirectories that make no sense (`trunk`, `tags`, and so on). If you want to make the `trunk` subdirectory be the new project root for every commit, `filter-branch` can help you do that, too: [source,console] diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc index 31b1e39d7..f4ce0e38a 100644 --- a/book/07-git-tools/sections/signing.asc +++ b/book/07-git-tools/sections/signing.asc @@ -81,7 +81,7 @@ Date: Mon Mar 17 21:52:11 2008 -0700 To verify a signed tag, you use `git tag -v `. This command uses GPG to verify the signature. -You need the signer’s public key in your keyring for this to work properly: +You need the signer's public key in your keyring for this to work properly: [source,console] ---- @@ -100,7 +100,7 @@ gpg: aka "[jpeg image of size 1513]" Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A ---- -If you don’t have the signer’s public key, you get something like this instead: +If you don't have the signer's public key, you get something like this instead: [source,console] ---- diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 686b5a871..7f88308f4 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -1,8 +1,8 @@ [[_git_stashing]] === Stashing and Cleaning -Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. -The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. +Often, when you've been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. +The problem is, you don't want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the `git stash` command. Stashing takes the dirty state of your working directory -- that is, your modified tracked files and staged changes -- and saves it on a stack of unfinished changes that you can reapply at any time (even on a different branch). @@ -19,7 +19,7 @@ But you might want to start migrating over to the `push` alternative for the new ==== Stashing Your Work -To demonstrate stashing, you’ll go into your project and start working on a couple of files and possibly stage one of the changes. +To demonstrate stashing, you'll go into your project and start working on a couple of files and possibly stage one of the changes. If you run `git status`, you can see your dirty state: [source,console] @@ -37,7 +37,7 @@ Changes not staged for commit: modified: lib/simplegit.rb ---- -Now you want to switch branches, but you don’t want to commit what you’ve been working on yet, so you’ll stash the changes. +Now you want to switch branches, but you don't want to commit what you've been working on yet, so you'll stash the changes. To push a new stash onto your stack, run `git stash` or `git stash push`: [source,console] @@ -59,7 +59,7 @@ nothing to commit, working directory clean ---- At this point, you can switch branches and do work elsewhere; your changes are stored on your stack. -To see which stashes you’ve stored, you can use `git stash list`: +To see which stashes you've stored, you can use `git stash list`: [source,console] ---- @@ -72,7 +72,7 @@ stash@{2}: WIP on master: 21d80a5 added number to log In this case, two stashes were saved previously, so you have access to three different stashed works. You can reapply the one you just stashed by using the command shown in the help output of the original stash command: `git stash apply`. If you want to apply one of the older stashes, you can specify it by naming it, like this: `git stash apply stash@{2}`. -If you don’t specify a stash, Git assumes the most recent stash and tries to apply it: +If you don't specify a stash, Git assumes the most recent stash and tries to apply it: [source,console] ---- @@ -90,13 +90,13 @@ no changes added to commit (use "git add" and/or "git commit -a") You can see that Git re-modifies the files you reverted when you saved the stash. In this case, you had a clean working directory when you tried to apply the stash, and you tried to apply it on the same branch you saved it from. -Having a clean working directory and applying it on the same branch aren’t necessary to successfully apply a stash. +Having a clean working directory and applying it on the same branch aren't necessary to successfully apply a stash. You can save a stash on one branch, switch to another branch later, and try to reapply the changes. You can also have modified and uncommitted files in your working directory when you apply a stash -- Git gives you merge conflicts if anything no longer applies cleanly. -The changes to your files were reapplied, but the file you staged before wasn’t restaged. +The changes to your files were reapplied, but the file you staged before wasn't restaged. To do that, you must run the `git stash apply` command with a `--index` option to tell the command to try to reapply the staged changes. -If you had run that instead, you’d have gotten back to your original position: +If you had run that instead, you'd have gotten back to your original position: [source,console] ---- @@ -197,7 +197,7 @@ Saved working directory and index state WIP on master: 1b65b17 added the index f ==== Creating a Branch from a Stash 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 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 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/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 0918af897..3732c63d0 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -2,14 +2,14 @@ === Submodules It often happens that while working on one project, you need to use another project from within it. -Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. +Perhaps it's a library that a third party developed or that you're developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other. -Here’s an example. -Suppose you’re developing a website and creating Atom feeds. +Here's an example. +Suppose you're developing a website and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. -You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. -The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. +You're likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. +The issue with including the library is that it's difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with copying the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. Git addresses this issue using submodules. @@ -55,7 +55,7 @@ Changes to be committed: ---- First you should notice the new `.gitmodules` file. -This is a configuration file that stores the mapping between the project’s URL and the local subdirectory you’ve pulled it into: +This is a configuration file that stores the mapping between the project's URL and the local subdirectory you've pulled it into: [source,ini] ---- @@ -64,9 +64,9 @@ This is a configuration file that stores the mapping between the project’s URL url = https://github.com/chaconinc/DbConnector ---- -If you have multiple submodules, you’ll have multiple entries in this file. -It’s important to note that this file is version-controlled with your other files, like your `.gitignore` file. -It’s pushed and pulled with the rest of your project. +If you have multiple submodules, you'll have multiple entries in this file. +It's important to note that this file is version-controlled with your other files, like your `.gitignore` file. +It's pushed and pulled with the rest of your project. This is how other people who clone this project know where to get the submodule projects from. [NOTE] @@ -92,7 +92,7 @@ index 0000000..c3f01dc +Subproject commit c3f01dc8862123d317dd46284b05b6892c7b29bc ---- -Although `DbConnector` is a subdirectory in your working directory, Git sees it as a submodule and doesn’t track its contents when you’re not in that directory. +Although `DbConnector` is a subdirectory in your working directory, Git sees it as a submodule and doesn't track its contents when you're not in that directory. Instead, Git sees it as a particular commit from that repository. If you want a little nicer diff output, you can pass the `--submodule` option to `git diff`. @@ -124,7 +124,7 @@ $ git commit -am 'added DbConnector module' ---- Notice the `160000` mode for the `DbConnector` entry. -That is a special mode in Git that basically means you’re recording a commit as a directory entry rather than a subdirectory or a file. +That is a special mode in Git that basically means you're recording a commit as a directory entry rather than a subdirectory or a file. Lastly, push these changes: @@ -136,7 +136,7 @@ $ git push origin master [[_cloning_submodules]] ==== Cloning a Project with Submodules -Here we’ll clone a project with a submodule in it. +Here we'll clone a project with a submodule in it. When you clone such a project, by default you get the directories that contain submodules, but none of the files within them yet: [source,console] @@ -789,7 +789,7 @@ This way you can simply run `git supdate` when you want to update your submodule ==== Issues with Submodules -Using submodules isn’t without hiccups, however. +Using submodules isn't without hiccups, however. For instance switching branches with submodules in them can also be tricky. If you create a new branch, add a submodule there, and then switch back to a branch without that submodule, you still have the submodule directory as an untracked directory: @@ -848,7 +848,7 @@ Makefile includes scripts src Again, not really very difficult, but it can be a little confusing. The other main caveat that many people run into involves switching from subdirectories to submodules. -If you’ve been tracking files in your project and you want to move them out into a submodule, you must be careful or Git will get angry at you. +If you've been tracking files in your project and you want to move them out into a submodule, you must be careful or Git will get angry at you. Assume that you have files in a subdirectory of your project, and you want to switch it to a submodule. If you delete the subdirectory and then run `submodule add`, Git yells at you: diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index 78a0b03f8..b6556985d 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -49,7 +49,7 @@ It's not common, because it's rarely helpful, but it's fairly easy to have branc In this case, we want to pull the Rack project into our `master` project as a subdirectory. We can do that in Git with `git read-tree`. -You’ll learn more about `read-tree` and its friends in <>, but for now know that it reads the root tree of one branch into your current staging area and working directory. +You'll learn more about `read-tree` and its friends in <>, but for now know that it reads the root tree of one branch into your current staging area and working directory. We just switched back to your `master` branch, and we pull the `rack_branch` branch into the `rack` subdirectory of our `master` branch of our main project: [source,console] @@ -87,7 +87,7 @@ We can keep branches with other related projects in our repository and subtree m It is nice in some ways, for example all the code is committed to a single place. However, it has other drawbacks in that it's a bit more complex and easier to make mistakes in reintegrating changes or accidentally pushing a branch into an unrelated repository. -Another slightly weird thing is that to get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch – to see if you need to merge them – you can’t use the normal `diff` command. +Another slightly weird thing is that to get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch – to see if you need to merge them – you can't use the normal `diff` command. Instead, you must run `git diff-tree` with the branch you want to compare to: [source,console] diff --git a/book/09-git-and-other-scms/sections/import-bzr.asc b/book/09-git-and-other-scms/sections/import-bzr.asc index 1d9cf677b..7dcbbd67a 100644 --- a/book/09-git-and-other-scms/sections/import-bzr.asc +++ b/book/09-git-and-other-scms/sections/import-bzr.asc @@ -114,7 +114,7 @@ git fast-import --import-marks=../marks.git --export-marks=../marks.git ---- Now `git branch` shows you the `master` branch as well as the `work` branch. -Check the logs to make sure they’re complete and get rid of the `marks.bzr` and `marks.git` files. +Check the logs to make sure they're complete and get rid of the `marks.bzr` and `marks.git` files. ===== Synchronizing the staging area diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index ad812f42c..0f7b84bd9 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -71,7 +71,7 @@ The question now is, when you run `git branch `, how does Git know the S The answer is the HEAD file. The HEAD file is a symbolic reference to the branch you're currently on. -By symbolic reference, we mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference. +By symbolic reference, we mean that unlike a normal reference, it doesn't generally contain a SHA-1 value but rather a pointer to another reference. If you look at the file, you'll normally see something like this: [source,console] diff --git a/book/introduction.asc b/book/introduction.asc index 111b4eac4..73c09d2e5 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -1,22 +1,22 @@ [preface] == Introduction -You’re about to spend several hours of your life reading about Git. Let’s take a minute to explain +You're about to spend several hours of your life reading about Git. Let's take a minute to explain what we have in store for you. Here is a quick summary of the ten chapters and three appendices of this book. -In *Chapter 1*, we’re going to cover Version Control Systems (VCSs) and Git basics -- no +In *Chapter 1*, we're going to cover Version Control Systems (VCSs) and Git basics -- no technical stuff, just what Git is, why it came about in a land full of VCSs, what sets it apart, and -why so many people are using it. Then, we’ll explain how to download Git and set it up for the -first time if you don’t already have it on your system. +why so many people are using it. Then, we'll explain how to download Git and set it up for the +first time if you don't already have it on your system. -In *Chapter 2*, we will go over basic Git usage -- how to use Git in the 80% of cases you’ll +In *Chapter 2*, we will go over basic Git usage -- how to use Git in the 80% of cases you'll encounter most often. After reading this chapter, you should be able to clone a repository, see what has happened in the history of the project, modify files, and contribute changes. If the book spontaneously combusts at this point, you should already be pretty useful wielding Git in the time it takes you to go pick up another copy. -*Chapter 3* is about the branching model in Git, often described as Git’s killer feature. Here -you’ll learn what truly sets Git apart from the pack. When you’re done, you may feel the need to +*Chapter 3* is about the branching model in Git, often described as Git's killer feature. Here +you'll learn what truly sets Git apart from the pack. When you're done, you may feel the need to spend a quiet moment pondering how you lived before Git branching was part of your life. *Chapter 4* will cover Git on the server. This chapter is for those of you who want to set up Git @@ -41,7 +41,7 @@ enforce a custom committing policy. *Chapter 9* deals with Git and other VCSs. This includes using Git in a Subversion (SVN) world and converting projects from other VCSs to Git. A lot of organizations still use SVN and are -not about to change, but by this point you’ll have learned the incredible power of Git -- and this +not about to change, but by this point you'll have learned the incredible power of Git -- and this chapter shows you how to cope if you still have to use a SVN server. We also cover how to import projects from several different systems in case you do convince everyone to make the plunge. @@ -66,4 +66,4 @@ Finally, in *Appendix C*, we go through all the major Git commands one at a time we covered them and what we did with them. If you want to know where in the book we used any specific Git command you can look that up here. -Let’s get started. +Let's get started. diff --git a/ch07-git-tools.asc b/ch07-git-tools.asc index b6e03c5cb..0e7fad551 100644 --- a/ch07-git-tools.asc +++ b/ch07-git-tools.asc @@ -1,10 +1,10 @@ [[ch07-git-tools]] == Git Tools -By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. -You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging. +By now, you've learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. +You've accomplished the basic tasks of tracking and committing files, and you've harnessed the power of the staging area and lightweight topic branching and merging. -Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point. +Now you'll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point. include::book/07-git-tools/sections/revision-selection.asc[] @@ -36,7 +36,7 @@ include::book/07-git-tools/sections/credentials.asc[] === Summary -You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. +You've seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. -If you want to use subprojects in your project, you’ve learned how to accommodate those needs. -At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so. +If you want to use subprojects in your project, you've learned how to accommodate those needs. +At this point, you should be able to do most of the things in Git that you'll need on the command line day to day and feel comfortable doing so.