From 3de81653fa7560ff5f4aa74eb87d7bd9a31ef4be Mon Sep 17 00:00:00 2001 From: Soon Van Date: Mon, 3 Dec 2012 22:56:49 -0500 Subject: [PATCH] Update progit.org links to git-scm.com book version Quickening event to redirect the links that used to be at progit.org to their new home at the git-scm.com book section. Deals with the English language links only. --- basic/index.html | 144 +++++++++++++++++++++---------------------- branching/index.html | 14 ++--- creating/index.html | 10 +-- index.html | 28 ++++----- inspect/index.html | 8 +-- remotes/index.html | 10 +-- 6 files changed, 107 insertions(+), 107 deletions(-) diff --git a/basic/index.html b/basic/index.html index db1c76a..effba37 100644 --- a/basic/index.html +++ b/basic/index.html @@ -5,7 +5,7 @@ layout: reference

- book + book Basic Snapshotting

@@ -19,13 +19,13 @@ layout: reference

An important concept here is that Git has an 'index', which acts as sort of a staging area for your snapshot. This allows you to build up a series - of well composed snapshots from changed files in your working directory, + of well composed snapshots from changed files in your working directory, rather than having to commit all of the file changes at once.

In a nutshell, you will use git add to start tracking new - files and also to stage changes to already tracked files, then + files and also to stage changes to already tracked files, then git status and git diff to see what has been modified and staged and finally git commit to record your snapshot into your history. This will be the basic workflow that you use @@ -39,7 +39,7 @@ layout: reference

docs   - book + book git add adds file contents to the staging area @@ -47,7 +47,7 @@ layout: reference

- In Git, you have to add file contents to your staging area before you + In Git, you have to add file contents to your staging area before you can commit them. If the file is new, you can run git add to initially add the file to your staging area, but even if the file is already "tracked" - ie, it was in your last commit - you still need @@ -56,7 +56,7 @@ layout: reference

Going back to our Hello World example, once we've initiated the project, - we would now start adding our files to it and we would do that with + we would now start adding our files to it and we would do that with git add. We can use git status to see what the state of our project is.

@@ -72,7 +72,7 @@ layout: reference 
 $ git add README hello.rb
- + Now if we run git status again, we'll see that they've been added. @@ -86,8 +86,8 @@ layout: reference It is also common to recursively add all files in a new project by specifying the current working directory like this: git add .. Since Git will recursively add all files under a directory you give it, if you give it - the current working directory, it will simply start tracking every file - there. In this case, a git add . would have done the same + the current working directory, it will simply start tracking every file + there. In this case, a git add . would have done the same thing as a git add README hello.rb, or for that matter so would git add *, but that's only because we don't have subdirectories which the * would not recurse into. @@ -111,15 +111,15 @@ layout: reference

- In a nutshell, - you run git add on a file when you want to + In a nutshell, + you run git add on a file when you want to include whatever changes you've made to it in your next commit snapshot. Anything you've changed that is not added will not be included - this means you can craft your snapshots with a bit more precision than most other SCM systems.

For a very interesting example of using this flexibility to stage only - parts of modified files at a time, see the '-p' option to + parts of modified files at a time, see the '-p' option to git add in the Pro Git book.

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

docs   - book + book git status view the status of your files in the working directory and staging area @@ -139,11 +139,11 @@ layout: reference

As you saw in the git add section, in order to see what the - status of your staging area is compared to the code in your working + status of your staging area is compared to the code in your working directory, you can run the git status command. I demonstrated using it with the -s option, which gives you short output. Without that flag, the git status command will give you more - context and hints. Here is the same status output with and without the + context and hints. Here is the same status output with and without the -s. The short output looks like this:

@@ -176,11 +176,11 @@ layout: reference

You can easily see how much more compact the short output is, but the - long output has useful tips and hints as to what commands you may want to + long output has useful tips and hints as to what commands you may want to use next.

-

Git will also tell you about files that were deleted since your last +

Git will also tell you about files that were deleted since your last commit or files that were modified or staged since your last commit.

@@ -192,7 +192,7 @@ layout: reference
     You can see there are two columns in the short status output.  The first
     column is for the staging area, the second is for the working directory.
     So for example, if you have the README file staged and then you modify
-    it again without running git add a second time, you'll see 
+    it again without running git add a second time, you'll see
     this:
 
 
@@ -202,8 +202,8 @@ layout: reference
 

 
     

-    In a nutshell, 
-    you run git status to see if anything has been modified 
+    In a nutshell,
+    you run git status to see if anything has been modified
     and/or staged since your last commit so you can decide if you want to
     commit a new snapshot and what will be recorded in it.
     

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

     
       docs  
-      book
+      book
     
     git diff
     shows diff of what is staged and what is modified but unstaged
@@ -223,7 +223,7 @@ layout: reference
 
   

     
There are two main uses of the git diff command.  One use we
-    will describe here, the other we will describe later in the 
+    will describe here, the other we will describe later in the
     "Inspection and Comparison"
     section. The way we're going to use it here is to describe the
     changes that are staged or modified on disk but unstaged.

@@ -250,16 +250,16 @@ index d62ac43..8d15d50 100644
 +++ b/hello.rb
 @@ -1,7 +1,7 @@
  class HelloWorld
-   
+
    def self.hello
 -    puts "hello world"
 +    puts "hola mundo"
    end
- 
+
  end
-

So where git status will show you what files have changed +

So where git status will show you what files have changed and/or been staged since your last commit, git diff will show you what those changes actually are, line by line. It's generally a good follow-up command to git status @@ -271,9 +271,9 @@ index d62ac43..8d15d50 100644

The git diff --cached command will show you what contents - have been staged. That is, this will show you the changes that will + have been staged. That is, this will show you the changes that will currently go into the next commit snapshot. So, if you were to stage - the change to hello.rb in the example above, + the change to hello.rb in the example above, git diff by itself won't show you any output because it will only show you what is not yet staged.

@@ -288,7 +288,7 @@ index d62ac43..8d15d50 100644 $ -

If you want to see the staged changes, you can run +

If you want to see the staged changes, you can run git diff --cached instead.

@@ -303,12 +303,12 @@ index d62ac43..8d15d50 100644
 +++ b/hello.rb
 @@ -1,7 +1,7 @@
  class HelloWorld
-   
+
    def self.hello
 -    puts "hello world"
 +    puts "hola mundo"
    end
- 
+
  end
@@ -320,7 +320,7 @@ index d62ac43..8d15d50 100644

If you want to see both staged and unstaged changes together, you can run git diff HEAD - this basically means you want to see the difference between your working directory and the last commit, - ignoring the staging area. If we make another change to our + ignoring the staging area. If we make another change to our hello.rb file then we'll have some changes staged and some changes unstaged. Here are what all three diff commands will show you:

@@ -333,12 +333,12 @@ index 4f40006..2ae9ba4 100644 +++ b/hello.rb @@ -1,7 +1,7 @@ class HelloWorld - + + # says hello def self.hello puts "hola mundo" end - + end $ git diff --cached diff --git a/hello.rb b/hello.rb @@ -347,12 +347,12 @@ index 2aabb6e..4f40006 100644 +++ b/hello.rb @@ -1,7 +1,7 @@ class HelloWorld - + def self.hello - puts "hello world" + puts "hola mundo" end - + end $ git diff HEAD diff --git a/hello.rb b/hello.rb @@ -361,13 +361,13 @@ index 2aabb6e..2ae9ba4 100644 +++ b/hello.rb @@ -1,7 +1,8 @@ class HelloWorld - + + # says hello def self.hello - puts "hello world" + puts "hola mundo" end - + end @@ -381,7 +381,7 @@ index 2aabb6e..2ae9ba4 100644 option, which will give us a summary of changes instead. Here is the same example as above, but using the --stat option instead.

- + 
 $ git status -s
 MM hello.rb
@@ -403,10 +403,10 @@ index 2aabb6e..2ae9ba4 100644
 
 
     

-    In a nutshell, 
+    In a nutshell,
     you run git diff to see details of the git status
     command - how files have been modified or staged on a line by line
-    basis. 
+    basis.
     

 
 
@@ -417,7 +417,7 @@ index 2aabb6e..2ae9ba4 100644
   

     
       docs  
-      book
+      book
     
     git commit
     records a snapshot of the staging area
@@ -425,7 +425,7 @@ index 2aabb6e..2ae9ba4 100644
 
   

 
-    
Now that you have staged the content you want to snapshot with the 
+    
Now that you have staged the content you want to snapshot with the
     git add command, you run git commit to actually
     record the snapshot.
     Git records your name and email address with every commit you make,
@@ -438,7 +438,7 @@ index 2aabb6e..2ae9ba4 100644

Let's stage and commit all the changes to our - hello.rb file. In this first example, we'll use the + hello.rb file. In this first example, we'll use the -m option to provide the commit message on the command line.

@@ -488,10 +488,10 @@ nothing to commit (working directory clean) the output of the git status command in there for you as a reminder of what you have modified and staged.

-

In general, it's very important to write a good commit message. +

In general, it's very important to write a good commit message. For open source projects, it's generally a rule to write your message more or less in this format:

- + 
 Short (50 chars or less) summary of changes
 
@@ -531,7 +531,7 @@ Further paragraphs come after blank lines.
     four commits of logically separate changes so that your work may be more
     easily peer reviewed.  Since there is a separation between committing and
     pushing those changes, do take the time to make it easier for the people
-    you are working with to see what you've done by putting each logically 
+    you are working with to see what you've done by putting each logically
     separate change in a separate commit with a nice commit message so it
     is easier for them to see what you are doing and why.

 
@@ -540,8 +540,8 @@ Further paragraphs come after blank lines.
       automatically stage all tracked, modified files before the commit

-

If you think the git add stage of the workflow is too - cumbersome, Git allows you to skip that part with the -a +

If you think the git add stage of the workflow is too + cumbersome, Git allows you to skip that part with the -a option. This basically tells Git to run git add on any file that is "tracked" - that is, any file that was in your last commit and has been modified. This allows you to do a more Subversion style workflow @@ -569,7 +569,7 @@ Further paragraphs come after blank lines. 1 files changed, 2 insertions(+), 1 deletions(-) -

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

Notice how if you don't stage any changes and then run git commit, Git will simply give you the output of the git status command, reminding you that nothing is staged. I've highlighted the important part of that message, saying that nothing @@ -584,7 +584,7 @@ Further paragraphs come after blank lines. to actually record the snapshot forever.

- In a nutshell, + In a nutshell, you run git commit to record the snapshot of your staged content. This snapshot can then be compared, shared and reverted to if you need to. @@ -597,7 +597,7 @@ Further paragraphs come after blank lines.

docs   - book + book git reset HEAD unstage changes that you have staged @@ -605,18 +605,18 @@ Further paragraphs come after blank lines.

git reset is probably the most confusing command written - by humans. I've been using Git for years, even wrote a book on it and I - still get confused by what it is going to do at times. So, I'll just - tell you the three specific invocations of it that are generally - helpful and ask you to blindly use it as I do - because it can be + by humans. I've been using Git for years, even wrote a book on it and I + still get confused by what it is going to do at times. So, I'll just + tell you the three specific invocations of it that are generally + helpful and ask you to blindly use it as I do - because it can be very useful.

-

In this case, we can use it to unstage something that you have +

In this case, we can use it to unstage something that you have accidentally staged. Let's say that you have modified two files and want to record them into two different commits. You should stage and commit one, then stage and commit the other. If you accidentally stage both of - them, how do you un-stage one? You do it with + them, how do you un-stage one? You do it with git reset HEAD -- file. Technically here you don't have to add the -- - it is used to tell Git when you have stopped listing options and are now listing file paths, but it's probably good to @@ -659,9 +659,9 @@ M hello.rb

If you want to be able to just run git unstage, you can easily - setup an alias in Git. Just run - git config --global alias.unstage "reset HEAD". - Once you have run that, you can then just run + setup an alias in Git. Just run + git config --global alias.unstage "reset HEAD". + Once you have run that, you can then just run git unstage [file] instead.

@@ -683,7 +683,7 @@ M hello.rb

- In a nutshell, + In a nutshell, you run git reset HEAD to unstage files that you previously ran git add on and wish to not include in the next commit snapshot

@@ -695,7 +695,7 @@ M hello.rb

docs   - book + book git rm remove files from the staging area @@ -703,18 +703,18 @@ M hello.rb
-

git rm will remove entries from the staging area. - This is a bit different from git reset HEAD which "unstages" - files. By "unstage" I mean it reverts the staging area to what was - there before we started modifying things. git rm on the - other hand just kicks the file off the stage entirely, so that it's not +

git rm will remove entries from the staging area. + This is a bit different from git reset HEAD which "unstages" + files. By "unstage" I mean it reverts the staging area to what was + there before we started modifying things. git rm on the + other hand just kicks the file off the stage entirely, so that it's not included in the next commit snapshot, thereby effectively deleting it.

-

By default, a git rm file will remove the file from the +

By default, a git rm file will remove the file from the staging area entirely and also off your disk (the working directory). To leave the file in the working directory, you can use git rm --cached .

- +

git mv git rm --cached orig; mv orig new; git add new @@ -725,7 +725,7 @@ M hello.rb Instead, it just tracks the snapshots and then figures out what files were likely renamed by comparing snapshots. If a file was removed from one snapshot and another file was added to the next one and the contents are - similar, Git figures it was most likely a rename. So, although the + similar, Git figures it was most likely a rename. So, although the git mv command exists, it is superfluous - all it does is a git rm --cached, moves the file on disk, then runs a git add on the new file. You don't really need to use it, but @@ -739,8 +739,8 @@ M hello.rb from your index, too.

- In a nutshell, - you run git rm to remove files from being tracked in Git. It + In a nutshell, + you run git rm to remove files from being tracked in Git. It will also remove them from your working directory.

diff --git a/branching/index.html b/branching/index.html index 735a140..1d9cb3a 100644 --- a/branching/index.html +++ b/branching/index.html @@ -5,7 +5,7 @@ layout: reference

- book + book Branching and Merging

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

docs   - book + book git branch list, create and manage working contexts @@ -50,7 +50,7 @@ layout: reference

docs   - book + book git checkout switch to a new branch context @@ -72,7 +72,7 @@ layout: reference

Without arguments, git branch will list out the local branches that you have. The branch that you are currently working on will have a star next to it and if you have - coloring turned on, + coloring turned on, will show the current branch in green.

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

docs   - book + book git merge merge a branch context into your current one @@ -473,7 +473,7 @@ M README

docs   - book + book git log show commit history of a branch @@ -696,7 +696,7 @@ ab5ab4c added erlang

docs   - book + book git tag tag a point in history as important diff --git a/creating/index.html b/creating/index.html index 279421d..a6f14b4 100644 --- a/creating/index.html +++ b/creating/index.html @@ -24,7 +24,7 @@ layout: reference

docs   - book + book git init initializes a directory as a Git repository @@ -75,7 +75,7 @@ Initialized empty Git repository in /opt/konichiwa/.git/

docs   - book + book git clone copy a git repository so you can add to it @@ -84,7 +84,7 @@ Initialized empty Git repository in /opt/konichiwa/.git/

If you need to collaborate with someone on a project, or if you want to get a copy of a project so you can look at or use the code, you will - clone it. You simply run the git clone [url] command with + clone it. You simply run the git clone [url] command with the URL of the project you want to copy.

@@ -120,14 +120,14 @@ config index objects

- By default, Git will create a directory that is the same name as the + By default, Git will create a directory that is the same name as the project in the URL you give it - basically whatever is after the last slash of the URL. If you want something different, you can just put it at the end of the command, after the URL.

- In a nutshell, you use git clone to get a + In a nutshell, you use git clone to get a local copy of a Git repository so you can look at it or start modifying it.

diff --git a/index.html b/index.html index bdee86e..e35f887 100644 --- a/index.html +++ b/index.html @@ -16,9 +16,9 @@ layout: reference Each section will link to the next section, so it can be used as a tutorial. Every page will also link to more in-depth Git documentation such as the official manual pages and relevant - sections in the Pro Git book, - so you can learn more about any of - the commands. First, we'll start with thinking about source code + sections in the Pro Git book, + so you can learn more about any of + the commands. First, we'll start with thinking about source code management like Git does.

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

The first thing that is important to understand about Git is - that it thinks about version control very differently than + that it thinks about version control very differently than Subversion or Perforce or whatever SCM you may be used to. It is often easier to learn Git by trying to forget your assumptions about how version control works and try to think about it in the @@ -37,16 +37,16 @@ layout: reference

- Let's start from scratch. Assume you are designing a new source + Let's start from scratch. Assume you are designing a new source code management system. How did you do basic version control before - you used a tool for it? Chances are that you simply copied your + you used a tool for it? Chances are that you simply copied your project directory to save what it looked like at that point. 

 $ cp -R project project.bak

- That way, you can easily revert files that get messed up later, or + That way, you can easily revert files that get messed up later, or see what you have changed by comparing what the project looks like now to what it looked like when you copied it.

@@ -59,8 +59,8 @@ layout: reference 
 $ cp -R project project.2010-06-01.bak

- In that case, you may have a bunch of snapshots of your project that - you can compare and inspect from. You can even use this model to + In that case, you may have a bunch of snapshots of your project that + you can compare and inspect from. You can even use this model to fairly effectively share changes with someone. If you zip up your project at a known state and put it on your website, other developers can download that, change it and send you a patch pretty easily. @@ -77,7 +77,7 @@ layout: reference

Now the original developer can apply that patch to their copy of the - project and they have your changes. This is how many open source + project and they have your changes. This is how many open source projects have been collaborated on for several years.

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

This is essentially what Git is. You tell Git you want to save a snapshot - of your project with the git commit command and it basically - records a manifest of what all of the files in your project look like at + of your project with the git commit command and it basically + records a manifest of what all of the files in your project look like at that point. Then most of the commands work with those manifests to see - how they differ or pull content out of them, etc. + how they differ or pull content out of them, etc.

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

If you think about Git as a tool for storing and comparing and merging snapshots of your project, - it may be easier to understand what is going on and how to do things + it may be easier to understand what is going on and how to do things properly.

diff --git a/inspect/index.html b/inspect/index.html index ee76fc0..765a831 100644 --- a/inspect/index.html +++ b/inspect/index.html @@ -5,7 +5,7 @@ layout: reference

- book + book Inspection and Comparison

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

docs   - book + book git log filter your commit history @@ -310,7 +310,7 @@ Date: Fri Jun 4 12:58:53 2010 +0200

docs   - book + book git diff @@ -471,4 +471,4 @@ index bb86f00..192151c 100644

And that's it! For more information, try reading the -Pro Git book.

+Pro Git book.

diff --git a/remotes/index.html b/remotes/index.html index 62a1531..abe0b10 100644 --- a/remotes/index.html +++ b/remotes/index.html @@ -5,7 +5,7 @@ layout: reference

- book + book Sharing and Updating Projects

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

docs   - book + book git remote list, add and delete remote repository aliases @@ -160,7 +160,7 @@ github git@github.com:schacon/hw.git (push)

docs   - book + book git fetch download new branches and data from a remote repository @@ -171,7 +171,7 @@ github git@github.com:schacon/hw.git (push)

docs   - book + book git pull fetch from a remote repo and try to merge into the current branch @@ -255,7 +255,7 @@ From github.com:schacon/hw

docs   - book + book git push push your new branches and data to a remote repository