From: Carl Worth <cworth@cworth.org>
Date: Fri, 28 Sep 2007 05:24:25 +0000 (-0700)
Subject: Port 2.6 (making and reviewing changes) from mercurial to git
X-Git-Url: https://git.cworth.org/git?p=hgbook-git;a=commitdiff_plain;h=7b55b40f9a1757afde7ccd40221c3537d6cd71ff

Port 2.6 (making and reviewing changes) from mercurial to git
---

diff --git a/tour.mdwn b/tour.mdwn
index 8c3951c..243737b 100644
--- a/tour.mdwn
+++ b/tour.mdwn
@@ -517,20 +517,25 @@ passing the -q or --quiet options.
 
 ### 2.6  Making and reviewing changes
 
-Now that we have a grasp of viewing history in Mercurial, let’s take a
+Now that we have a grasp of viewing history in git, let’s take a
 look at making some changes and examining them.
 
 The first thing we’ll do is isolate our experiment in a repository of
-its own. We use the “hg clone” command, but we don’t need to clone a
+its own. We use the “git clone” command, but we don’t need to clone a
 copy of the remote repository. Since we already have a copy of it
 locally, we can just clone that instead. This is much faster than
 cloning over the network, and cloning a local repository uses less
 disk space in most cases, too.
 
-	$ cd ..   
-	$ hg clone hello my-hello   
-	2 files updated, 0 files merged, 0 files removed, 0 files unresolved   
-	$ cd my-hello
+	$ cd ..
+	$ git clone hello my-hello
+	Initialized empty Git repository in /home/cworth/src/hgbook-git/my-hello/.git/
+	0 blocks
+
+	[XXX We say "empty" here, (presumably from the git-init part),
+	but shouldn't the command also report the succesful clone
+	which makes it non-empty? And what the heck does "0 blocks"
+	mean?]
 
 As an aside, it’s often good practice to keep a “pristine” copy of a
 remote repository around, which you can then make temporary clones of
@@ -540,6 +545,17 @@ until it’s complete and you’re ready to integrate it back. Because
 local clones are so cheap, there’s almost no overhead to cloning and
 destroying repositories whenever you want.
 
+Alternatively, you can achieve much the same effect by creating
+multiple branches in a single repository, (but we won't go into detail
+on how to do that in this chapter). Some people greatly appreciate
+having multiple branches in a single repository rather than having
+many repositories cluttering up their filesystem. Other people prefer
+the ability to have working-tree changes, and intermediate build
+files, etc. each isolated in a separate repository per branch. Both
+modes are very well-supported by git, so it's really a matter of which
+you find most appropriate at any time given your tastes and project
+workflows.
+
 In our my-hello repository, we have a file hello.c that contains the
 classic “hello, world” program. Let’s use the ancient and venerable
 sed command to edit this file so that it prints a second line of
@@ -548,40 +564,46 @@ scripted example this way. Since you’re not under the same constraint,
 you probably won’t want to use sed; simply use your preferred text
 editor to do the same thing.)
 
-	$ sed -i '/printf/a∖∖tprintf("hello again!∖∖n");' hello.c
-
-Mercurial’s “hg status” command will tell us what Mercurial knows
-about the files in the repository.
-
-	$ ls   
-	Makefile  hello.c   
-	$ hg status   
-	M hello.c
+	$ sed -i '/printf/a\\tprintf("hello again!\\n");' hello.c       
 
-The “hg status” command prints no output for some files, but a line
-starting with “M” for hello.c. Unless you tell it to, “hg status” will
-not print any output for files that have not been modified.
+The “git status” command will tell us what git knows about the files
+in the repository.
 
-The “M” indicates that Mercurial has noticed that we modified
-hello.c. We didn’t need to inform Mercurial that we were going to
-modify the file before we started, or that we had modified the file
-after we were done; it was able to figure this out itself.
+	$ ls 
+	hello.c  Makefile
+	$ git status
+	# On branch master
+	# Changed but not updated:
+	#   (use "git add <file>..." to update what will be committed)
+	#
+	#       modified:   hello.c
+	#
+	no changes added to commit (use "git add" and/or "git commit -a")
+
+We see that “git status” command prints a line with "modified" for
+hello.c. The “git status” command will not print any output for files
+that have not been modified.
+
+Notice that we didn’t need to inform git that we were going to modify
+the file before we started, or that we had modified the file after we
+were done; it was able to figure this out itself.
 
 It’s a little bit helpful to know that we’ve modified hello.c, but we
 might prefer to know exactly what changes we’ve made to it. To do
-this, we use the “hg diff” command.
+this, we use the “git diff” command.
 
-	$ hg diff   
-	diff -r b57f9a090b62 hello.c   
-	--- a/hello.c Tue Sep 06 15:43:07 2005 -0700   
-	+++ b/hello.c Sun Jun 17 18:05:50 2007 +0000   
-	@@ -8,5 +8,6 @@ int main(int argc, char ⋆⋆argv)   
-	int main(int argc, char ⋆⋆argv)   
-	{   
-	printf("hello, world!∖");   
-	+ printf("hello again!∖n");   
-	return 0;   
-	}
+	$ git diff
+	diff --git a/hello.c b/hello.c
+	index 9a3ff79..6d28887 100644
+	--- a/hello.c
+	+++ b/hello.c
+	@@ -8,5 +8,6 @@
+	 int main(int argc, char **argv)
+	 {
+	        printf("hello, world!\");
+	+       printf("hello again!\n");
+	        return 0;
+	 }
 
 ### 2.7  Recording changes in a new changeset