@git / git-reference / commits / 7057ccb

updated all the book urls

Scott Chacon committed Jun 10, 2010 at 14:24 UTC 7057ccb078b6a2cc2370416a11251d1e7a91d92f

3 files changed +148 -148

branching/index.html

+70 -70

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

5 <div class="box">

6 <h2>

7

8 - <a target="new" href="http://progit.org/book/ch2-2.html">book</a>

8 + <a target="new" href="http://progit.org/book/ch3-0.html">book</a>

9

10 Branching and Merging

11 </h2>

@@ -14,21 +14,21 @@ layout: reference

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

17 - using them. When you checkout different branches, you change contexts

17 + using them. When you checkout different branches, you change contexts

18 that you are working in and you can quickly context-switch back and forth

19 between several different branches.

20

22

23 - In a nutshell you can create a branch with

23 + In a nutshell you can create a branch with

24 <code>git branch (branchname)</code>, switch into that context with

25 <code>git checkout (branchname)</code>, record commit snapshots while

26 in that context, then can switch back and forth easily. When you switch

27 branches, Git replaces your working directory with the snapshot of the

28 latest commit on that branch so you don't have to have multiple directories

29 - for multiple branches. You merge branches together with

29 + for multiple branches. You merge branches together with

30 <code>git merge</code>. You can easily merge multiple times from the same

31 - branch over time, or alternately you can choose to delete a branch

31 + branch over time, or alternately you can choose to delete a branch

32 immediately after merging it.

33

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

39 <h2>

40

41 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-branch.html">docs</a>

42 - <a target="new" href="http://progit.org/book/">book</a>

42 + <a target="new" href="http://progit.org/book/ch3-2.html">book</a>

43

44 <a name="branch">git branch</a>

45 list, create and manage working contexts

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

50 <h2>

51

52 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html">docs</a>

53 - <a target="new" href="http://progit.org/book/">book</a>

53 + <a target="new" href="http://progit.org/book/ch3-2.html">book</a>

54

55 <a name="checkout">git checkout</a>

56 switch to a new branch context

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

69 list your available branches

70 </h4>

72 - Without arguments, <code>git branch</code> will list out the local

72 + Without arguments, <code>git branch</code> will list out the local

73 branches that you have. The branch that you are currently working on will

74 - have a star next to it and if you have

75 - <a href="http://progit.org/book/ch7-1.html#colors_in_git">coloring turned on</a>,

74 + have a star next to it and if you have

75 + <a href="http://progit.org/book/ch7-1.html#colors_in_git">coloring turned on</a>,

76 will show the current branch in green.

77

@@ -105,7 +105,7 @@ $ git branch

105

106 Now we can see that we have a new branch. When you create a branch this

107 way it creates the branch at your last commit so if you record some commits

108 - at this point and then switch to 'testing', it will revert your working

108 + at this point and then switch to 'testing', it will revert your working

109 directory context back to when you created the branch in the first place -

110 you can think of it like a bookmark for where you currently are. Let's see

111 this in action - we use <code>git checkout (branch)</code> to switch the

@@ -188,20 +188,20 @@ README hello.rb more.txt test.txt

188 contexts we can switch between.

189

190

191 - If you start on work it is very useful to

191 + If you start on work it is very useful to

192 always start it in a branch (because it's fast and easy to do) and then

193 merge it in and delete the branch when you're done. That way if what you're

194 working on doesn't work out you can easily discard it and if you're forced

195 to switch back to a more stable context your work in progress is easy to put

196 aside and then come back to.

197 -

197 +

198 <h4>

199 git branch -d (branchname)

200 delete a branch

201 </h4>

202

203 - If we want to delete a branch (such as the 'testing' branch in the

204 - previous example, since there is no unique work on it),

203 + If we want to delete a branch (such as the 'testing' branch in the

204 + previous example, since there is no unique work on it),

205 we can run <code>git branch -d (branch)</code> to remove it.

206

207 <pre>

@@ -215,8 +215,8 @@ Deleted branch testing (was 78b2670).

215 </pre>

216

217

218 - In a nutshell you use <code>git branch</code> to list your

219 - current branches, create new branches and delete unnecessary or

218 + In a nutshell you use <code>git branch</code> to list your

219 + current branches, create new branches and delete unnecessary or

220 already merged branches.

221

222

@@ -227,20 +227,20 @@ Deleted branch testing (was 78b2670).

227 <h2>

228

229 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-merge.html">docs</a>

230 - <a target="new" href="http://progit.org/book/">book</a>

230 + <a target="new" href="http://progit.org/book/ch3-2.html#basic_merging">book</a>

231

232 <a name="merge">git merge</a>

233 merge a branch context into your current one

234 </h2>

235

236 <div class="block">

237 - Once you have work isolated in a branch, you will eventually want to

237 + Once you have work isolated in a branch, you will eventually want to

238 incorporate it into your main branch. You can merge any branch into your

239 - current branch with the <code>git merge</code> command. Let's take as a

239 + current branch with the <code>git merge</code> command. Let's take as a

240 simple example the 'removals' branch from above. If we create a branch

241 - and remove files in it and commit our removals to that branch, it is

241 + and remove files in it and commit our removals to that branch, it is

242 isolated from our main ('master', in this case) branch. To include those

243 - deletions in your 'master' branch, you can just merge in the 'removals'

243 + deletions in your 'master' branch, you can just merge in the 'removals'

244 branch.

245

246

@@ -266,7 +266,7 @@ Fast-forward

266 more complex merges

267 </h4>

268

269 - Of course, this doesn't just work for simple file additions and

269 + Of course, this doesn't just work for simple file additions and

270 deletions. Git will merge file modifications as well - in fact, it's very

271 good at it. For example, let's see what happens when we edit a file in

272 one branch and in another branch we rename it and then edit it and then

@@ -286,8 +286,8 @@ end

286 HelloWorld.hello

287 </pre>

288

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

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

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

290 + switch to it so your class renaming changes are isolated. I'm going to

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

292

293 <pre>

@@ -301,10 +301,10 @@ class HiWorld

301 [change_class 3467b0a] changed the class name

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

303 </pre>

304 -

304 +

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

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

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

307 + revert to what it was before I switched branches. Here I can change

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

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

310

@@ -321,12 +321,12 @@ index 2aabb6e..bf64b17 100644

321 +++ b/ruby.rb

322 @@ -1,7 +1,7 @@

323 class HelloWorld

324 -

324 +

325 def self.hello

326 - puts "Hello World"

327 + puts "Hello World from Ruby"

328 end

329 -

329 +

330 end

331 $ git commit -am 'added from ruby'

332 [master b7ae93b] added from ruby

@@ -335,9 +335,9 @@ index 2aabb6e..bf64b17 100644

335 </pre>

336

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

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

338 + class name is back to 'HelloWorld', not 'HiWorld'. Now I want to

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

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

340 + branch. However, I've changed the name of the file since I branched,

341 what will Git do?

342

343 <pre>

@@ -373,7 +373,7 @@ HiWorld.hello

373 of code is edited in different branches there is no way for a computer

374 to figure it out, so it's up to us. Let's see another example of changing

375 the same line in two branches.

376 -

376 +

377

378 <pre>

379 $ git branch

@@ -387,7 +387,7 @@ Switched to a new branch 'fix_readme'

387 </pre>

388

389 Now we have committed a change to one line in our README file in a

390 - branch. Now let's change the same line in a different way back on

390 + branch. Now let's change the same line in a different way back on

391 our 'master' branch.

392

393 <pre>

@@ -422,7 +422,7 @@ nearly every programming language.

422 Subversion, into files when it gets a merge conflict. Now it's up to us

423 to resolve them. We will do it manually here, but check out

424 <a href="http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html">git mergetool</a>

425 - if you want Git to fire up a graphical mergetool

425 + if you want Git to fire up a graphical mergetool

426 (like kdiff3, emerge, p4merge, etc) instead.

427

428

@@ -437,14 +437,14 @@ index 9103e27,69cad1a..0000000

437 - Many Hello World Examples

438 -Hello World Lang Examples

439 ++Many Hello World Lang Examples

440 -

440 +

441 This project has examples of hello world in

442 </pre>

443

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

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

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

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

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

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

449

450 <pre>

@@ -456,7 +456,7 @@ M README

456 $ git commit

457 [master 8d585ea] Merge branch 'fix_readme'

458 </pre>

459 -

459 +

460 And now we've successfully resolved our merge conflict and committed

461 the result.

462

@@ -474,7 +474,7 @@ M README

474 <h2>

475

476 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-log.html">docs</a>

477 - <a target="new" href="http://progit.org/book/">book</a>

477 + <a target="new" href="http://progit.org/book/ch6-1.html#commit_ranges">book</a>

478

479 <a name="log">git log</a>

480 show commit history of a branch

@@ -490,8 +490,8 @@ M README

490 <code>git log</code>.

491

492 To understand the log command, you have to understand what information

493 - is stored when you run the <code>git commit</code> command to store a

494 - snapshot. In addition to the manifest of files and commit message and

493 + is stored when you run the <code>git commit</code> command to store a

494 + snapshot. In addition to the manifest of files and commit message and

495 information about the person who committed it, Git also stores the commit

496 that you based this snapshot on. That is, if you clone a project, what was

497 the snapshot that you modified to get to the snapshot that you saved? This

@@ -503,8 +503,8 @@ M README

503

504 To see a chronological list of the parents of any branch, you can run

505 <code>git log</code> when you are in that branch. For example, if we run

506 - <code>git log</code> in the Hello World project that we have been working

507 - on in this section, we'll see all the commit messages that we've done.

506 + <code>git log</code> in the Hello World project that we have been working

507 + on in this section, we'll see all the commit messages that we've done.

508

509 <pre>

510 $ git log

@@ -514,7 +514,7 @@ Author: Scott Chacon <schacon@gmail.com>

514 Date: Fri Jun 4 12:59:47 2010 +0200

515

516 Merge branch 'fix_readme'

517 -

517 +

518 Conflicts:

519 README

520

@@ -539,7 +539,7 @@ Date: Fri Jun 4 12:37:05 2010 +0200

539 ...

540 </pre>

541

542 - To see a more compact version of the same history, we can use the

542 + To see a more compact version of the same history, we can use the

543 <code>--oneline</code> option.

544

545 <pre>

@@ -565,28 +565,28 @@ b7ae93b added from ruby

565 <pre>

566 $ git log --oneline --graph

567 * 8d585ea Merge branch 'fix_readme'

568 -|\

568 +|\

569 | * 3ac015d fixed readme title

570 * | 3cbb6aa fixed readme title differently

571 -|/

571 +|/

572 * 558151a Merge branch 'change_class'

573 -|\

573 +|\

574 | * 3467b0a changed the class name

575 * | b7ae93b added from ruby

576 -|/

576 +|/

577 * 17f4acf first commit

578 </pre>

579

580 Now we can more clearly see when effort diverged and then was merged

581 - back together. This is very nice for seeing what has happened or what

581 + back together. This is very nice for seeing what has happened or what

582 changes are applied, but

583 it is also incredibly useful for managing your branches. Let's create a new

584 - branch, do some work in it and then switch back and do some work in our

584 + branch, do some work in it and then switch back and do some work in our

585 master branch, then see how the <code>log</code> command can help us figure

586 out what is happening on each.

587

588 First we'll create a new branch to add the Erlang programming language

589 - Hello World example - we want to do this in a branch so that we don't

589 + Hello World example - we want to do this in a branch so that we don't

590 muddy up our stable branch with code that may not work for a while so we

591 can cleanly switch in and out of it.

592

@@ -634,8 +634,8 @@ README ruby.rb

634 things to do. When we come back we want to know what the 'erlang' branch

635 is all about and where we've left off on the master branch. Just by looking

636 at the branch name, we can't know that we made Haskell changes in there, but

637 - using <code>git log</code> we easily can. If you give Git a branch name,

638 - it will show you just the commits that are "reachable" in the history of

637 + using <code>git log</code> we easily can. If you give Git a branch name,

638 + it will show you just the commits that are "reachable" in the history of

639 that branch, that is the commits that influenced the final snapshot.

640

641 <pre>

@@ -652,15 +652,15 @@ b7ae93b added from ruby

652 </pre>

653

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

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

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

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

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

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

659

660

661 -

662 - In this case if we are interested in merging in the 'erlang' branch we

663 - want to see what commits are going to effect our snapshot when we do

661 +

662 + In this case if we are interested in merging in the 'erlang' branch we

663 + want to see what commits are going to effect our snapshot when we do

664 that merge. The way we tell Git that is by putting a <code>^</code> in

665 front of the branch that we don't want to see. For instance, if we want

666 to see the commits that are in the 'erlang' branch that are not in the

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

686 at the tip of the branch. This allows you to see how the project in that

687 context got to the state that it is currently in.

688

689 -

689 +

690 </div>

691 </div>

692

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

694 <h2>

695

696 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-tag.html">docs</a>

697 - <a target="new" href="http://progit.org/book/">book</a>

697 + <a target="new" href="http://progit.org/book/ch2-6.html">book</a>

698

699 <a name="log">git tag</a>

700 tag a point in history as important

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

723 </pre>

724

725 When you run the <code>git tag -a</code> command, Git will open your editor

726 - and have you write a tag message, just like you would write a commit

726 + and have you write a tag message, just like you would write a commit

727 message.

728

729 Now, notice when we run <code>git log --decorate</code>, we can see our

@@ -733,26 +733,26 @@ ab5ab4c added erlang

733 $ git log --oneline --decorate --graph

734 * 594f90b (HEAD, tag: v1.0, master) reverted to old class name

735 * 8d585ea Merge branch 'fix_readme'

736 -|\

736 +|\

737 | * 3ac015d (fix_readme) fixed readme title

738 * | 3cbb6aa fixed readme title differently

739 -|/

739 +|/

740 * 558151a Merge branch 'change_class'

741 -|\

741 +|\

742 | * 3467b0a changed the class name

743 * | b7ae93b added from ruby

744 -|/

744 +|/

745 * 17f4acf first commit

746 </pre>

747

748 If we do more commits, the tag will stay right at that commit, so we have

749 - that specific snapshot tagged forever and can always compare future

749 + that specific snapshot tagged forever and can always compare future

750 snapshots to it.

751

752 We don't have to tag the commit that we're on, however. If we forgot to

753 tag a commit that we released, we can retroactively tag it by running the

754 same command, but with the commit SHA at the end. For example, say we had

755 - released commit <code>558151a</code> (several commits back) but forgot to

755 + released commit <code>558151a</code> (several commits back) but forgot to

756 tag it at the time. We can just tag it now:

757

758 <pre>

@@ -760,15 +760,15 @@ ab5ab4c added erlang

760 $ git log --oneline --decorate --graph

761 * 594f90b (HEAD, tag: v1.0, master) reverted to old class name

762 * 8d585ea Merge branch 'fix_readme'

763 -|\

763 +|\

764 | * 3ac015d (fix_readme) fixed readme title

765 * | 3cbb6aa fixed readme title differently

766 -|/

766 +|/

767 * 558151a (tag: v0.9) Merge branch 'change_class'

768 -|\

768 +|\

769 | * 3467b0a changed the class name

770 * | b7ae93b added from ruby

771 -|/

771 +|/

772 * 17f4acf first commit

773 </pre>

774

inspect/index.html

+47 -47

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

5 <div class="box">

6 <h2>

7

8 - <a target="new" href="http://progit.org/book">book</a>

8 + <a target="new" href="http://progit.org/book/ch2-3.html">book</a>

9

10 Inspection and Comparison

11 </h2>

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

18

20

21 - In a nutshell you can use <code>git log</code> to find specific

21 + In a nutshell you can use <code>git log</code> to find specific

22 commits in your project history - by author, date, content or

23 history. You can use <code>git diff</code> to compare two different points

24 - in your history - generally to see how two branches differ or what has

24 + in your history - generally to see how two branches differ or what has

25 changed from one version of your software to another.

26

27 </div>

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

31 <h2>

32

33 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-log.html">docs</a>

34 - <a target="new" href="http://progit.org/book/">book</a>

34 + <a target="new" href="http://progit.org/book/ch2-3.html">book</a>

35

36 <a name="log">git log</a>

37 filter your commit history

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

55

56 To filter your commit history to only the ones done by a specific author,

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

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

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

62 results to the last [number] commits.

63

@@ -79,7 +79,7 @@ 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

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):

@@ -106,7 +106,7 @@ b6c8d2d Documentation/remote-helpers: Add invocation section

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

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

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

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

112

@@ -114,22 +114,22 @@ b6c8d2d Documentation/remote-helpers: Add invocation section

114 <pre>

115 $ git log --grep=P4EDITOR --no-merges

116 commit 82cea9ffb1c4677155e3e2996d76542502611370

117 -Author: Shawn Bohrer

117 +Author: Shawn Bohrer

118 Date: Wed Mar 12 19:03:24 2008 -0500

119

120 git-p4: Use P4EDITOR environment variable when set

121 -

121 +

122 Perforce allows you to set the P4EDITOR environment variable to your

123 preferred editor for use in perforce. Since we are displaying a

124 perforce changelog to the user we should use it when it is defined.

125 -

125 +

126 Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>

127 Signed-off-by: Simon Hausmann <simon@lst.de>

128 </pre>

129

130 -

130 +

131 Git will logically OR all <code>--grep</code> and <code>--author</code>

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

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

@@ -146,7 +146,7 @@ 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

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

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

152

@@ -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, if I add a <code>--all-match</code>, I get the results I'm

171 looking for:

172

173 <pre>

@@ -181,11 +181,11 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.

181 </h4>

182

183

184 - What if you write really horrible commit messages? Or, what if you are

185 - looking for when a function was introduced, or where variables started

186 - to be used? You can also tell Git to look through the diff of each

184 + What if you write really horrible commit messages? Or, what if you are

185 + looking for when a function was introduced, or where variables started

186 + to be used? You can also tell Git to look through the diff of each

187 commit for a string. For example, if we wanted to find which commits

188 - modified anything that looked like the function name

188 + modified anything that looked like the function name

189 'userformat_find_requirements', we would run this: (note there is no '='

190 between the '-S' and what you are searching for)

191

@@ -193,21 +193,21 @@ e96e400 Simon Hausmann git-p4: Fix submit user-interface.

193 <pre>

194 $ git log -Suserformat_find_requirements

195 commit 5b16360330822527eac1fa84131d185ff784c9fb

196 -Author: Johannes Gilger

196 +Author: Johannes Gilger

197 Date: Tue Apr 13 22:31:12 2010 +0200

198

199 pretty: Initialize notes if %N is used

200 -

200 +

201 When using git log --pretty='%N' without an explicit --show-notes, git

202 would segfault. This patches fixes this behaviour by loading the needed

203 notes datastructures if --pretty is used and the format contains %N.

204 When --pretty='%N' is used together with --no-notes, %N won't be

205 expanded.

206 -

206 +

207 This is an extension to a proposed patch by Jeff King.

208 -

209 - Signed-off-by: Johannes Gilger

210 - Signed-off-by: Junio C Hamano

208 +

209 + Signed-off-by: Johannes Gilger

210 + Signed-off-by: Junio C Hamano

211 </pre>

212

213 <h4>

@@ -220,7 +220,7 @@ Date: Tue Apr 13 22:31:12 2010 +0200

220 snapshot it was based off of, Git can always calculate the difference and

221 show it to you as a patch. That means for any commit you can get the patch

222 that commit introduced to the project. You can either do this by running

223 - <code>git show [SHA]</code> with a specific commit SHA, or you can run

223 + <code>git show [SHA]</code> with a specific commit SHA, or you can run

224 <code>git log -p</code>, which tells Git to put the patch after each commit.

225 It is a great way to summarize what has happened on a branch or between

226 commits.

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

245 puts "Hello World from Ruby"

246 end

247 end

248 -

248 +

249 -HiWorld.hello

250 +HelloWorld.hello

251

@@ -263,7 +263,7 @@ index d053cc8..9103e27 100644

263 -Hello World Examples

264 +Many Hello World Examples

265 ======================

266 -

266 +

267 This project has examples of hello world in

268 </pre>

269

@@ -310,7 +310,7 @@ Date: Fri Jun 4 12:58:53 2010 +0200

310 <h2>

311

312 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-diff.html">docs</a>

313 - <a target="new" href="http://progit.org/book/">book</a>

313 + <a target="new" href="http://progit.org/book/ch5-3.html#determining_what_is_introduced">book</a>

314

315 <a name="diff">git diff</a>

316

@@ -318,15 +318,15 @@ Date: Fri Jun 4 12:58:53 2010 +0200

318

319 <div class="block">

320

321 - Finally, to see the absolute changes between any two commit snapshots,

321 + Finally, to see the absolute changes between any two commit snapshots,

322 you can use the <code>git diff</code> command. This is largely used in two

323 - main situations - seeing how two branches differ from one another and

324 - seeing what has changed since a release or some other older point in

323 + main situations - seeing how two branches differ from one another and

324 + seeing what has changed since a release or some other older point in

325 history. Let's look at both of these situations.

326

327 To see what has changed since the last release, you can simply run

328 - <code>git diff [version]</code> (or whatever you tagged the release).

329 - For example, if we want to see what has changed in our project since

328 + <code>git diff [version]</code> (or whatever you tagged the release).

329 + For example, if we want to see what has changed in our project since

330 the v0.9 release, we can run <code>git diff v0.9</code>.

331

332

@@ -340,7 +340,7 @@ index d053cc8..d4173d5 100644

340 -Hello World Examples

341 +Many Hello World Lang Examples

342 ======================

343 -

343 +

344 This project has examples of hello world in

345 diff --git a/ruby.rb b/ruby.rb

346 index bb86f00..192151c 100644

@@ -353,12 +353,12 @@ index bb86f00..192151c 100644

353 puts "Hello World from Ruby"

354 end

355 end

356 -

356 +

357 -HiWorld.hello

358 +HelloWorld.hello

359 </pre>

360

361 - Just like <code>git log</code>, you can use the <code>--stat</code>

361 + Just like <code>git log</code>, you can use the <code>--stat</code>

362 option with it.

363

364 <pre>

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

373 exactly what you are asking - it will basically give you a patch file that

374 would turn the snapshot at the tip of branchA into the snapshot at the tip

375 of branchB. This means if the two branches have diverged - gone in different

376 - directions - it will remove all the work that was introduced into branchA

376 + directions - it will remove all the work that was introduced into branchA

377 and then add everything that was introduced into branchB. This is probably

378 not what you want - you want the changes added to branchB that are not in

379 branchA, so you really want the difference between where the two branches

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

384 * 594f90b (HEAD, tag: v1.0, master) reverted to old class name

385 | * 1834130 (erlang) added haskell

386 | * ab5ab4c added erlang

387 -|/

387 +|/

388 * 8d585ea Merge branch 'fix_readme'

389 ...

390 </pre>

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

403

404 You see that it adds the erlang and haskell files, which is what we did

405 in that branch, but then the output also reverts the changes to the ruby file

406 - that we did in the master branch. What we really want to see is just the

406 + that we did in the master branch. What we really want to see is just the

407 changes that happened in the "erlang" branch (adding the two files). We can

408 get the desired result by doing the diff from the common commit they diverged

409 from:

@@ -416,9 +416,9 @@ index bb86f00..192151c 100644

416 </pre>

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

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 three dots in between the branch names), Git will automatically figure out

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

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

422 commit is and do the diff off of that.

423

424 <pre>

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

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

438

439

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

440 + As a bit of an aside, you can also have git manually calculate the

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

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

443

@@ -462,13 +462,13 @@ index bb86f00..192151c 100644

462

463 In a nutshell you can use <code>git diff</code> to see how a project

464 has changed since a known point in the past or to see what unique work is

465 - in one branch since it diverged from another. Always use

466 - <code>git diff branchA...branchB</code> to inspect branchB relative to

465 + in one branch since it diverged from another. Always use

466 + <code>git diff branchA...branchB</code> to inspect branchB relative to

467 branchA to make things easier.

468

469

470 </div>

471 </div>

472

473 -And that's it! For more information, try reading the

473 +And that's it! For more information, try reading the

474 <a href="http://progit.org">Pro Git book</a>.

remotes/index.html

+31 -31

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

5 <div class="box">

6 <h2>

7

8 - <a target="new" href="http://progit.org/book">book</a>

8 + <a target="new" href="http://progit.org/book/ch2-5.html">book</a>

9

10 Sharing and Updating Projects

11 </h2>

12 <div class="block">

13

14 Git doesn't have a central server like Subversion. All of the commands

15 - so far have been done locally, just updating a local database.

16 - To collaborate with other developers in Git, you have to put all that

15 + so far have been done locally, just updating a local database.

16 + To collaborate with other developers in Git, you have to put all that

17 data on a server that the other developers have access to. The way Git

18 does this is to syncronize your data with another repository. There

19 is no real difference between a server and a client - a Git repository

@@ -27,14 +27,14 @@ layout: reference

27

29 You can do this any time you are online, it does not have to correspond

30 - with a <code>commit</code> or anything else. Generally you will do a

30 + with a <code>commit</code> or anything else. Generally you will do a

31 number of commits locally, then fetch data from the online shared repository

32 you cloned the project from to get up to date, merge any new work into the

33 stuff you did, then push your changes back up.

35

36 In a nutshell you can update your project with <code>git fetch</code>

37 - and share your changes with <code>git push</code>. You can manage your

37 + and share your changes with <code>git push</code>. You can manage your

38 remote repositories with <code>git remote</code>.

39

40 </div>

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

44 <h2>

45

46 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-remote.html">docs</a>

47 - <a target="new" href="http://progit.org/book/">book</a>

47 + <a target="new" href="http://progit.org/book/ch2-5.html#showing_your_remotes">book</a>

48

49 <a name="push">git remote</a>

50 list, add and delete remote repository aliases

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

59 and others that you can write to as well.

61 So that you don't have to use the full URL of a remote repository every

62 - time you want to syncronize with it, Git stores an alias or nickname for

63 - each remote repository URL you are interested in. You use the

62 + time you want to syncronize with it, Git stores an alias or nickname for

63 + each remote repository URL you are interested in. You use the

64 <code>git remote</code> command to manage this list of remote repos that

65 you care about.

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

70 </h4>

72 Without any arguments, Git will simply show you the remote repository

73 - aliases that it has stored. By default, if you cloned the project (as

73 + aliases that it has stored. By default, if you cloned the project (as

74 opposed to creating a new one locally), Git will automatically add the

75 URL of the repository that you cloned from under the name 'origin'. If

76 - you run the command with the <code>-v</code> option, you can see the

76 + you run the command with the <code>-v</code> option, you can see the

77 actual URL for each alias.

79 <pre>

@@ -94,12 +94,12 @@ origin git@github.com:schacon/git-reference.git (push)

94 </h4>

96 If you want to share a locally created repository, or you want to take

97 - contributions from someone elses repository - if you want to interact in

97 + contributions from someone elses repository - if you want to interact in

98 any way with a new repository, it's generally easiest to add it as a remote.

99 You do that by running <code>git remote add [alias] [url]</code>. That

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,

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),

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

@@ -114,9 +114,9 @@ github git@github.com:schacon/hw.git (push)

114 </pre>

115

116 Like the branch naming, remote alias names are arbitrary - just as 'master'

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

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.

122

@@ -147,9 +147,9 @@ github git@github.com:schacon/hw.git (push)

147 </pre>

148

149

150 - In a nutshell with <code>git remote</code> you can list our

150 + In a nutshell with <code>git remote</code> you can list our

151 remote repositories and whatever URL

152 - that repository is using. You can use <code>git remote add</code> to

152 + that repository is using. You can use <code>git remote add</code> to

153 add new remotes and <code>git remote rm</code> to delete existing ones.

154

155

@@ -160,7 +160,7 @@ github git@github.com:schacon/hw.git (push)

160 <h2>

161

162 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html">docs</a>

163 - <a target="new" href="http://progit.org/book/">book</a>

163 + <a target="new" href="http://progit.org/book/ch2-5.html#fetching_and_pulling_from_your_remotes">book</a>

164

165 <a name="fetch">git fetch</a>

166 download new branches and data from a remote repository

@@ -181,9 +181,9 @@ github git@github.com:schacon/hw.git (push)

181

182 Git has two commands to update itself from a remote repository.

183 <code>git fetch</code> will syncronize you with another repo, pulling down any data

184 - that you do not have locally and giving you bookmarks to where each branch on

184 + that you do not have locally and giving you bookmarks to where each branch on

185 that remote was when you syncronized. These are called "remote branches" and are

186 - identical to local branches except that Git will not allow you to check them out -

186 + identical to local branches except that Git will not allow you to check them out -

187 however, you can merge from them, diff them to other branches, run history logs on

188 them, etc. You do all of that stuff locally after you syncronize.

189

@@ -201,7 +201,7 @@ github git@github.com:schacon/hw.git (push)

201 Assuming you have a remote all set up and you want to pull in updates, you

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

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

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

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

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

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

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

@@ -216,7 +216,7 @@ Resolving deltas: 100% (1526/1526), completed with 387 local objects.

216 From github.com:schacon/hw

217 8e29b09..c7c5a10 master -> github/master

218 0709fdc..d4ccf73 c-langs -> github/c-langs

219 - 6684f82..ae06d2b java -> github/java

219 + 6684f82..ae06d2b java -> github/java

220 * [new branch] ada -> github/ada

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

222 </pre>

@@ -228,11 +228,11 @@ From github.com:schacon/hw

228 into 'master'.

229

230

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

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

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

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

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

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

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

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

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

238

@@ -242,8 +242,8 @@ From github.com:schacon/hw

242 with all of your remotes by running <code>git fetch --all</code>.

243

244

245 - In a nutshell you run <code>git fetch [alias]</code> to syncronize your

246 - repository with a remote repository, fetching all the data it has that you do

245 + In a nutshell you run <code>git fetch [alias]</code> to syncronize your

246 + repository with a remote repository, fetching all the data it has that you do

247 not into branch references locally for merging and whatnot.

248

249

@@ -255,7 +255,7 @@ From github.com:schacon/hw

255 <h2>

256

257 <a target="new" href="http://www.kernel.org/pub/software/scm/git/docs/git-push.html">docs</a>

258 - <a target="new" href="http://progit.org/book/">book</a>

258 + <a target="new" href="http://progit.org/book/ch2-5.html#pushing_to_your_remotes">book</a>

259

260 <a name="push">git push</a>

261 push your new branches and data to a remote repository

@@ -263,7 +263,7 @@ From github.com:schacon/hw

263

264 <div class="block">

265 To share the cool commits you've done with others, you need to push your

266 - changes to the remote repository. To do this, you run

266 + changes to the remote repository. To do this, you run

267 <code>git push [alias] [branch]</code> which will attempt to make your [branch]

268 the new [branch] on the [alias] remote. Let's try it by initially pushing

269 our 'master' branch to the new 'github' remote we created earlier.

@@ -304,15 +304,15 @@ To git@github.com:schacon/hw.git

304

305 The last major issue you run into with pushing to remote branches is the

306 case of someone pushing in the meantime. If you and another developer clone

307 - at the same time, you both do commits, then she pushes and then you try to

307 + at the same time, you both do commits, then she pushes and then you try to

308 push, Git will by default not allow you to overwrite her changes. Instead,

309 it basically runs <code>git log</code> on the branch you're trying to push and

310 makes sure it can see the current tip of the servers branch in your pushes

311 history. If it can't see what is on the server in your history, it concludes

312 that you are out of date and will reject your push. You will rightly have to

313 - fetch, merge then push again - which makes sure you take her changes into

313 + fetch, merge then push again - which makes sure you take her changes into

314 account.

315 -

315 +

316 This is what happens when you try to push a branch to a remote branch

317 that has been updated in the meantime:

318