@git / git-reference / commits / cdc6f3d

Remove pronoun I from voice for lack of lone addressor

There is no single author listed, the credits are to the GitHub team, so match up narration to fit that angle. Pulls it back from single author perspective driving it that may have existed long ago.

Soon Van committed Jan 26, 2013 at 23:06 UTC cdc6f3d5065f2fbf750b67398d666d2d1d8c680e

5 files changed +68 -70

basic/index.html

+14 -16

@@ -140,8 +140,8 @@ layout: reference

140 <div class="block">

141 As you saw in the <code>git add</code> section, in order to see what the

142 status of your staging area is compared to the code in your working

143 - directory, you can run the <code>git status</code> command. I demonstrated

144 - using it with the <code>-s</code> option, which gives you short output.

143 + directory, you can run the <code>git status</code> command. Using the

144 + <code>-s</code> option will give you short output.

145 Without that flag, the <code>git status</code> command will give you more

146 context and hints. Here is the same status output with and without the

147 <code>-s</code>. The short output looks like this:

@@ -572,7 +572,7 @@ Further paragraphs come after blank lines.

572 Notice how if you don't stage any changes and then run

573 <code>git commit</code>, Git will simply give you the output of the

574 <code>git status</code> command, reminding you that nothing is staged.

575 - I've highlighted the important part of that message, saying that nothing

575 + The important part of that message has been highlighted, saying that nothing

576 is added to be committed. If you use <code>-a</code>, it will add and

577 commit everything at once.

578

@@ -605,11 +605,9 @@ Further paragraphs come after blank lines.

605

606 <div class="block">

607 <code>git reset</code> is probably the most confusing command written

608 - by humans. I've been using Git for years, even wrote a book on it and I

609 - still get confused by what it is going to do at times. So, I'll just

610 - tell you the three specific invocations of it that are generally

611 - helpful and ask you to blindly use it as I do - because it can be

612 - very useful.

608 + by humans, but it can be very useful when you get the hang of it.

609 + There are three specific invocations of it that are generally

610 + helpful.

611

612

613 <h4>

@@ -617,19 +615,19 @@ Further paragraphs come after blank lines.

615 undo the last commit and unstage the files

616 </h4>

617

620 - In the first case, we can use it to unstage something that you have

618 + First, you can use it to unstage something that has been

619 accidentally staged. Let's say that you have modified two files and want

620 to record them into two different commits. You should stage and commit

621 one, then stage and commit the other. If you accidentally stage both of

622 them, how do you un-stage one? You do it with

625 - <code>git reset HEAD -- file</code>. Technically here you don't have to

623 + <code>git reset HEAD -- file</code>. Technically you don't have to

624 add the <code>--</code> - it is used to tell Git when you have stopped

625 listing options and are now listing file paths, but it's probably good to

626 get into the habit of using it to separate options from paths even if you

627 don't need to.

628

629

632 - So, let's see what it looks like to unstage something. Here we have

630 + Let's see what it looks like to unstage something. Here we have

631 two files that have been modified since our last commit. We will stage

632 both, then unstage one of them.

633

@@ -782,7 +780,7 @@ nothing to commit (working directory clean)

780

781 <code>git rm</code> will remove entries from the staging area.

782 This is a bit different from <code>git reset HEAD</code> which "unstages"

785 - files. By "unstage" I mean it reverts the staging area to what was

783 + files. To "unstage" means it reverts the staging area to what was

784 there before we started modifying things. <code>git rm</code> on the

785 other hand just kicks the file off the stage entirely, so that it's not

786 included in the next commit snapshot, thereby effectively deleting it.

@@ -810,10 +808,10 @@ nothing to commit (working directory clean)

808

809

810

813 - I personally don't use this command that much in it's normal form - to

814 - delete files. It's often easier to just remove the files off your disk and

815 - then run a <code>git commit -a</code>, which will automatically remove them

816 - from your index, too.

811 + In its normal form the command is used to delete files.

812 + But it's often easier to just remove the files off your disk and

813 + then run <code>git commit -a</code>, which will also automatically remove

814 + them from your index.

815

816

817 In a nutshell,

branching/index.html

+14 -14

@@ -10,7 +10,7 @@ layout: reference

10 Branching and Merging

11 </h2>

12 <div class="block">

13 - Branching in Git is one of my favorite features. If you have used other

13 + Branching in Git is one of its many great features. If you have used other

14 version control systems, it's probably helpful to forget most of what you

15 think about branches - in fact, it may be more helpful to think of them

16 practically as contexts since that is how you will most often be

@@ -319,7 +319,7 @@ HelloWorld.hello

319 </pre>

320

321 So first we're going to create a new branch named 'change_class' and

322 - switch to it so your class renaming changes are isolated. I'm going to

322 + switch to it so your class renaming changes are isolated. We're going to

323 change each instance of 'HelloWorld' to 'HiWorld'.

324

325 <pre>

@@ -333,9 +333,9 @@ class HiWorld

333 1 files changed, 2 insertions(+), 4 deletions(-)

334 </pre>

335

336 - So now I've committed the class renaming changes to the 'change_class'

337 - branch. If I now switch back to the 'master' branch my class name will

338 - revert to what it was before I switched branches. Here I can change

336 + So now we've committed the class renaming changes to the 'change_class'

337 + branch. To switch back to the 'master' branch the class name will

338 + revert to what it was before we switched branches. Here we can change

339 something different (in this case the printed output) and at the same

340 time rename the file from <code>hello.rb</code> to <code>ruby.rb</code>.

341

@@ -365,10 +365,10 @@ index 2aabb6e..bf64b17 100644

365 rename hello.rb => ruby.rb (65%)

366 </pre>

367

368 - Now those changes are recorded in my 'master' branch. Notice that the

369 - class name is back to 'HelloWorld', not 'HiWorld'. Now I want to

370 - incorporate the 'HiWorld' change so I can just merge in my 'change_class'

371 - branch. However, I've changed the name of the file since I branched,

368 + Now those changes are recorded in the 'master' branch. Notice that the

369 + class name is back to 'HelloWorld', not 'HiWorld'. To incorporate

370 + the 'HiWorld' change we can just merge in the 'change_class'

371 + branch. However, the name of the file has changed since we branched,

372 what will Git do?

373

374 <pre>

@@ -391,7 +391,7 @@ end

391 HiWorld.hello

392 </pre>

393

394 - Well, it will just figure it out. Notice that I had no merge conflicts

394 + Well, it will just figure it out. Notice that there are no merge conflicts

395 and the file that had been renamed now has the 'HiWorld' class name change

396 that was done in the other branch. Pretty cool.

397

@@ -474,9 +474,9 @@ index 9103e27,69cad1a..0000000

474

475 A cool tip in doing merge conflict resolution in Git is that if you

476 run <code>git diff</code>, it will show you both sides of the conflict

477 - and how you've resolved it as I've shown here. Now it's time to mark

477 + and how you've resolved it as shown here. Now it's time to mark

478 the file as resolved. In Git we do that with <code>git add</code> -

479 - to tell Git the file has been resolved, you have to stage it.

479 + to tell Git the file has been resolved you have to stage it.

480

481 <pre>

482 $ git status -s

@@ -684,7 +684,7 @@ b7ae93b added from ruby

684 </pre>

685

686 This way, it's pretty easy to see that we have Haskell code included in

687 - the branch (as I've highlighted). What is even cooler is that we can

687 + the branch (highlighted in the output). What is even cooler is that we can

688 easily tell Git that we only are interested in the commits that are

689 reachable in one branch that are not reachable in another, in other words

690 which commits are unique to a branch in comparison to another.

@@ -751,7 +751,7 @@ ab5ab4c added erlang

751 tag", which allows you to add a tag message to it, which is what you almost

752 always want to do. Running this without the <code>-a</code> works too, but

753 it doesn't record when it was tagged, who tagged it, or let you add a tag

754 - message. I would recommend always creating annotated tags.

754 + message. It's recommended you always create annotated tags.

755

756 <pre>

757 $ git tag -a v1.0

index.html

+2 -2

@@ -5,7 +5,7 @@ layout: reference

5 <h2>Introduction to the Git Reference</h2>

6 <div class="block">

7

8 - This is the Git reference site. This is meant to be a quick

8 + This is the Git reference site. It is meant to be a quick

9 reference for learning and remembering the most important and

10 commonly used Git commands. The commands are organized into

11 sections of the type of operation you may be trying to do, and

@@ -28,7 +28,7 @@ layout: reference

28 <h2>How to Think Like Git</h2>

29 <div class="block">

30

31 - The first thing that is important to understand about Git is

31 + The first important thing to understand about Git is

32 that it thinks about version control very differently than

33 Subversion or Perforce or whatever SCM you may be used to. It

34 is often easier to learn Git by trying to forget your assumptions

inspect/index.html

+18 -18

@@ -57,8 +57,8 @@ layout: reference

57 you can use the <code>--author</code> option. For example, let's say we're

58 looking for the commits in the Git source code done by Linus. We would

59 type something like <code>git log --author=Linus</code>. The search is

60 - case sensitive and also will search the email address. I'll do the

61 - example using the <code>-[number]</code> option, which will limit the

60 + case sensitive and will also search the email address. The following

61 + example will use the <code>-[number]</code> option, which will limit the

62 results to the last [number] commits.

63

@@ -78,11 +78,11 @@ b532581 make "git unpack-file" a built-in

79

80 If you want to specify a date range that you're interested in filtering your

81 - commits down to, you can use a number of options - I use <code>--since</code>

82 - and <code>--before</code>, but you can also use <code>--until</code> and

83 - <code>--after</code>. For example, if I wanted to see all the commits in

84 - the Git project before 3 weeks ago but after April 18th, I could run this

85 - (I'm also going to use <code>--no-merges</code> to remove merge commits):

81 + commits down to, you can use a number of options such as <code>--since</code>

82 + and <code>--before</code>, or you can also use <code>--until</code> and

83 + <code>--after</code>. For example, to see all the commits in

84 + the Git project before three weeks ago but after April 18th, you could run this

85 + (We're also going to use <code>--no-merges</code> to remove merge commits):

86

88 <pre>

@@ -105,9 +105,9 @@ b6c8d2d Documentation/remote-helpers: Add invocation section

105

106

107 You may also want to look for commits with a certain phrase in the commit

108 - message. You can use <code>--grep</code> for that. Let's say I knew there

108 + message. Use <code>--grep</code> for that. Let's say there

109 was a commit that dealt with using the P4EDITOR environment variable and

110 - I wanted to remember what that change looked like - I could find the commit

110 + you wanted to remember what that change looked like - you could find the commit

111 with <code>--grep</code>.

112

113

@@ -132,11 +132,11 @@ Date: Wed Mar 12 19:03:24 2008 -0500

132 arguments. If you want to use <code>--grep</code> and <code>--author</code>

133 to see commits that were authored by someone AND have a specific message

134 content, you have to add the <code>--all-match</code> option. In these

135 - examples, I'm going to use the <code>--format</code> option, so we can see

135 + examples we're going to use the <code>--format</code> option, so we can see

136 who the author of each commit was.

137

138

139 - If I look for the commit messages with 'p4 depo' in them, I get these

139 + If we look for the commit messages with 'p4 depo' in them, we get these

140 three commits:

141

142 <pre>

@@ -146,8 +146,8 @@ da4a660 Benjamin Sergeant git-p4 fails when cloning a p4 depo.

146 1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d

147 </pre>

148

149 - If I add a <code>--author=Hausmann</code> argument, instead of further

150 - filtering it down to the one commit by Simon, it instead will show me all

149 + If we add a <code>--author=Hausmann</code> argument, instead of further

150 + filtering it down to the one commit by Simon, it instead will show all

151 commits by Simon OR commits with "p4 depo" in the message:

152

153 <pre>

@@ -167,7 +167,7 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.

167 ...

168 </pre>

169

170 - However, if I add a <code>--all-match</code>, I get the results I'm

170 + However, adding <code>--all-match</code> will get the results you're

171 looking for:

172

173 <pre>

@@ -417,7 +417,7 @@ index bb86f00..192151c 100644

417

418 That's what we're looking for, but we don't want to have to figure out

419 what commit the two branches diverged from every time. Luckily, Git has a

420 - shortcut for this. If you run <code>git diff master...erlang</code> (with

420 + shortcut for this. If you run <code>git diff master...erlang</code> (with

421 three dots in between the branch names), Git will automatically figure out

422 what the common commit (otherwise known as the "merge base") of the two

423 commit is and do the diff off of that.

@@ -438,7 +438,7 @@ index bb86f00..192151c 100644

438 the triple-dot syntax, because it will almost always give you what you want.

439

440

441 - As a bit of an aside, you can also have git manually calculate the

441 + As a bit of an aside, you can also have Git manually calculate what the

442 merge-base (first common ancestor commit) of any two commits would be with

443 the <code>git merge-base</code> command:

444

@@ -447,7 +447,7 @@ index bb86f00..192151c 100644

447 8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d

448 </pre>

449

450 - So, you can do the equivalent of <code>git diff master...erlang</code>

450 + You can do the equivalent of <code>git diff master...erlang</code>

451 by running this:

452

453 <pre>

@@ -457,7 +457,7 @@ index bb86f00..192151c 100644

457 2 files changed, 9 insertions(+), 0 deletions(-)

458 </pre>

459

460 - I would of course recommend using the easier syntax, though.

460 + You may prefer using the easier syntax though.

461

462

463

remotes/index.html

+20 -20

@@ -100,7 +100,7 @@ origin git@github.com:github/git-reference.git (push)

100 adds <code>[url]</code> under a local remote named <code>[alias]</code>.

101

102 For example, if we want to share our Hello World program with the world,

103 - we can create a new repository on a server (I'll use GitHub as an example),

103 + we can create a new repository on a server (Using GitHub as an example),

104 which should give you a URL, in this case "git@github.com:schacon/hw.git".

105 To add that to our project so we can push to it and fetch updates from it

106 we would do this:

@@ -117,8 +117,8 @@ github git@github.com:schacon/hw.git (push)

117 has no special meaning but is widely used because <code>git init</code>

118 sets it up by default, 'origin' is often used as a remote name because

119 <code>git clone</code> sets it up by default as the cloned-from URL. In

120 - this case I've decided to name my remote 'github', but I could have really

121 - named it just about anything.

120 + this case we'll name the remote 'github', but you could name it just

121 + about anything.

122

123

124 <h4>

@@ -266,10 +266,10 @@ fatal: No such remote 'guhflub'

266 The second command that will fetch down new data from a remote server is

267 <code>git pull</code>. This command will basically run a <code>git fetch</code>

268 immediately followed by a <code>git merge</code> of the branch on that remote

269 - that is tracked by whatever branch you are currently in. I personally don't much

270 - like this command - I prefer running <code>fetch</code> and <code>merge</code>

271 - separately. Less magic, less problems. However, if you like this idea, you

272 - can read about it in more detail in the

269 + that is tracked by whatever branch you are currently in. Running the

270 + <code>fetch</code> and <code>merge</code> commands separately involves less magic

271 + and less problems, but if you like the idea of <code>pull</code>, you can

272 + read about it in more detail in the

273 <a target="new" href="http://git-scm.com/docs/git-pull">official docs</a>.

274

275

@@ -277,9 +277,9 @@ fatal: No such remote 'guhflub'

277 would first run <code>git fetch [alias]</code> to tell Git to fetch down all the

278 data it has that you do not, then you would run <code>git merge [alias]/[branch]</code>

279 to merge into your current branch anything new you see on the server

280 - (like if someone else has pushed in the meantime). So, if I were working on my

281 - Hello World project with several other people and I wanted to bring in any changes

282 - that had been pushed since I last connected, I would do something like this:

280 + (like if someone else has pushed in the meantime). So, if you were working on a

281 + Hello World project with several other people and wanted to bring in any changes

282 + that had been pushed since we last connected, we would do something like this:

283

284 <pre>

285 $ git fetch github

@@ -296,17 +296,17 @@ From github.com:schacon/hw

296 * [new branch] lisp -> github/lisp

297 </pre>

298

299 - I can see that since the last time I synchronized with this remote, five branches

299 + Here we can see that since we last synchronized with this remote, five branches

300 have been added or updated. The 'ada' and 'lisp' branches are new, where the

301 - 'master', 'c-langs' and 'java' branches have been updated. In this case, my team

302 - is pushing proposed updates to remote branches for review before they're merged

303 - into 'master'.

301 + 'master', 'c-langs' and 'java' branches have been updated. In our example case,

302 + other developers are pushing proposed updates to remote branches for review before

303 + they're merged into 'master'.

304

305

306 You can see the mapping that Git makes. The 'master' branch on the remote

307 - repository becomes a branch named 'github/master' locally. That way now I can

308 - merge the 'master' branch on that remote into my local 'master' branch by running

309 - <code>git merge github/master</code>. Or, I can see what new commits are on that

307 + repository becomes a branch named 'github/master' locally. That way you can

308 + merge the 'master' branch on that remote into the local 'master' branch by running

309 + <code>git merge github/master</code>. Or, you can see what new commits are on that

310 branch by running <code>git log github/master ^master</code>. If your remote

311 is named 'origin' it would be <code>origin/master</code> instead. Almost any

312 command you would run using local branches you can use remote branches with too.

@@ -356,10 +356,10 @@ To git@github.com:schacon/hw.git

356 </pre>

357

358 Pretty easy. Now if someone clones that repository they will get exactly

359 - what I have committed and all of its history.

359 + what we have committed and all of its history.

360

361 - What if I have a topic branch like the 'erlang' branch we created earlier

362 - and I just want to share that? You can just push that branch instead.

361 + What if you have a topic branch like the 'erlang' branch created earlier

362 + and want to share just that? You can just push that branch instead.

363

364 <pre>

365 $ git push github erlang