Structural rearrangement

en/book/01-introduction/chapter1.asc

@@ -230,6 +230,9 @@ You can also check what Git thinks a specific key’s value is by typing `git co
   $ git config user.name
   Scott Chacon
 
+==== Credential Caching
+
+
 === Getting Help
 
 If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands:

en/book/02-git-basics/chapter2.asc

@@ -625,6 +625,22 @@ You can see the commit history in the top half of the window along with a nice a
 
 At any stage, you may want to undo something. Here, we’ll review a few basic tools for undoing changes that you’ve made. Be careful, because you can’t always undo some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong.
 
+==== Reset Demystified
+
+===== The Three Trees
+
+===== The Workflow
+
+===== The Role of Reset
+
+===== Reset With a Path
+
+===== A Fun Example
+
+===== Check It Out
+
+===== Summary
+
 ==== Changing Your Last Commit
 
 One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. If you want to try that commit again, you can run commit with the `--amend` option:
@@ -703,6 +719,8 @@ You can see that the changes have been reverted. You should also realize that th
 
 Remember, anything that is committed in Git can almost always be recovered. Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see Chapter 9 for data recovery). However, anything you lose that was never committed is likely never to be seen again.
 
+==== Undoing All Changes
+
 === Working with Remotes
 
 To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work.

en/book/03-git-branching/chapter3.asc

@@ -280,6 +280,8 @@ If you’re happy with that, and you verify that everything that had conflicts h
 
 You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future — why you did what you did, if it’s not obvious.
 
+==== Undoing Merges
+
 === Branch Management
 
 Now that you’ve created, merged, and deleted some branches, let’s look at some branch-management tools that will come in handy when you begin using branches all the time.
@@ -554,6 +556,8 @@ You have to merge that work in at some point so you can keep up with the other d
 
 If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble.
 
+==== Rebase vs. Merge
+
 === Summary
 
 We’ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together.  You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared.

en/book/06-github/chapter6.asc

@@ -0,0 +1,107 @@
+== GitHub
+
+GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project.
+
+GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done.
+
+=== Setting Up a User Account
+
+The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see figure 4-2), you’re taken to the signup page.
+
+image::images/18333fig0402-tn.png[Figure 4-2. The GitHub plan page.]
+
+Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3).
+
+image::images/18333fig0403-tn.png[Figure 4-3. The GitHub user signup form.]
+
+If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems.
+Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4).
+
+image::images/18333fig0404-tn.png[Figure 4-4. The GitHub user dashboard.]
+
+Next you can create a new repository.
+
+=== Creating a New Repository
+
+Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5).
+
+image::images/18333fig0405-tn.png[Figure 4-5. Creating a new repository on GitHub.]
+
+All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6).
+
+image::images/18333fig0406-tn.png[Figure 4-6. GitHub project header information.]
+
+Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7).
+
+image::images/18333fig0407-tn.png[Figure 4-7. Instructions for a new repository.]
+
+These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use
+
+  $ git init
+  $ git add .
+  $ git commit -m 'initial commit'
+
+When you have a Git repository locally, add GitHub as a remote and push up your master branch:
+
+  $ git remote add origin [email protected]:testinguser/iphone_project.git
+  $ git push origin master
+
+Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8).
+
+image::images/18333fig0408-tn.png[Figure 4-8. Project header with a public URL and a private URL.]
+
+The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you.
+
+The Your Clone URL is a read/write SSH-based URL that you can read or write over only if you connect with the SSH private key associated with the public key you uploaded for your user. When other users visit this project page, they won’t see that URL—only the public one.
+
+=== Importing from Subversion
+
+If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9).
+
+image::images/18333fig0409-tn.png[Figure 4-9. Subversion importing interface.]
+
+If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports.
+
+=== Adding Collaborators
+
+Let’s add the rest of the team. If John, Josie, and Jessica all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project as collaborators. Doing so will allow pushes from their public keys to work.
+
+Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10).
+
+image::images/18333fig0410-tn.png[Figure 4-10. GitHub administration page.]
+
+To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11).
+
+image::images/18333fig0411-tn.png[Figure 4-11. Adding a collaborator to your project.]
+
+When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12).
+
+image::images/18333fig0412-tn.png[Figure 4-12. A list of collaborators on your project.]
+
+If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project.
+
+=== Your Project
+
+After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13.
+
+image::images/18333fig0413-tn.png[Figure 4-13. A GitHub main project page.]
+
+When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information.
+
+=== Forking Projects
+
+If you want to contribute to an existing project to which you don’t have push access, GitHub encourages forking the project. When you land on a project page that looks interesting and you want to hack on it a bit, you can click the "fork" button in the project header to have GitHub copy that project to your user so you can push to it.
+
+This way, projects don’t have to worry about adding users as collaborators to give them push access. People can fork a project and push to it, and the main project maintainer can pull in those changes by adding them as remotes and merging in their work.
+
+To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14).
+
+image::images/18333fig0414-tn.png[Figure 4-14. Get a writable copy of any repository by clicking the "fork" button.]
+
+After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15).
+
+image::images/18333fig0415-tn.png[Figure 4-15. Your fork of a project.]
+
+=== GitHub Summary
+
+That’s all we’ll cover about GitHub, but it’s important to note how quickly you can do all this. You can create an account, add a new project, and push to it in a matter of minutes. If your project is open source, you also get a huge community of developers who now have visibility into your project and may well fork it and help contribute to it. At the very least, this may be a way to get up and running with Git and try it out quickly.

en/book/06-git-tools/chapter6.asc → en/book/07-git-tools/chapter7.asc

@@ -525,6 +525,8 @@ If you stash some work, leave it there for a while, and continue on the branch f
 
 This is a nice shortcut to recover stashed work easily and work on it in a new branch.
 
+=== Searching
+
 === Rewriting History
 
 Many times, when working with Git, you may want to revise your commit history for some reason. One of the great things about Git is that it allows you to make decisions at the last possible moment. You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with the stash command, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others.
@@ -1120,6 +1122,20 @@ Or, to compare what is in your `rack` subdirectory with what the `master` branch
 
   $ git diff-tree -p rack_remote/master
 
+=== Notes
+
+=== Bundle
+
+=== Rerere
+
+=== History Hacks
+
+==== Grafts (?)
+
+==== Replace
+
+==== Shallow
+
 === Summary
 
 You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. If you want to use subprojects in your project, you’ve learned a few ways to accommodate those needs. At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so.

en/book/08-git-and-other-scms/chapter8.asc → en/book/09-git-and-other-scms/chapter9.asc

@@ -343,6 +343,12 @@ The `git svn` tools are useful if you’re stuck with a Subversion server for no
 
 If you follow those guidelines, working with a Subversion server can be more bearable. However, if it’s possible to move to a real Git server, doing so can gain your team a lot more.
 
+=== Git and Mercurial
+
+=== Git and Perforce
+
+=== Git and TFS
+
 === Migrating to Git
 
 If you have an existing codebase in another VCS but you’ve decided to start using Git, you must migrate your project one way or another. This section goes over some importers that are included with Git for common systems and then demonstrates how to develop your own custom importer.
@@ -415,6 +421,8 @@ Because you want all your branches and tags to go up, you can now run this:
 
 All your branches and tags should be on your new Git server in a nice, clean import.
 
+==== Mercurial
+
 ==== Perforce
 
 The next system you’ll look at importing from is Perforce. A Perforce importer is also distributed with Git, but only in the `contrib` section of the source code — it isn’t available by default like `git svn`. To run it, you must get the Git source code, which you can download from git.kernel.org:
@@ -484,6 +492,8 @@ If you run `git log`, you can see that all the SHA-1 checksums for the commits h
 
 Your import is ready to push up to your new Git server.
 
+==== TFS
+
 ==== A Custom Importer
 
 If your system isn’t Subversion or Perforce, you should look for an importer online — quality importers are available for CVS, Clear Case, Visual Source Safe, even a directory of archives. If none of these tools works for you, you have a rarer tool, or you otherwise need a more custom importing process, you should use `git fast-import`. This command reads simple instructions from stdin to write specific Git data. It’s much easier to create Git objects this way than to run the raw Git commands or try to write the raw objects (see Chapter 9 for more information). This way, you can write an import script that reads the necessary information out of the system you’re importing from and prints straightforward instructions to stdout. You can then run this program and pipe its output through `git fast-import`.
@@ -684,6 +694,8 @@ There you go — a nice, clean Git repository. It’s important to note that not
 
 You can do a lot more with the `fast-import` tool — handle different modes, binary data, multiple branches and merging, tags, progress indicators, and more. A number of examples of more complex scenarios are available in the `contrib/fast-import` directory of the Git source code; one of the better ones is the `git-p4` script I just covered.
 
+=== A Custom Credential Cache
+
 === Summary
 
 You should feel comfortable using Git with Subversion or importing nearly any existing repository into a new Git one without losing data. The next chapter will cover the raw internals of Git so you can craft every single byte, if need be.

en/book/10-git-in-other-environments/chapter10.asc

@@ -0,0 +1,31 @@
+== Git in Other Environments
+
+=== Graphical Interfaces
+
+==== gitk & git-gui
+
+==== GitHub for Windows/Mac
+
+==== Other GUIs
+
+=== Git in Visual Studio
+
+=== Git in Eclipse
+
+=== Git in Bash
+
+=== Git in Zsh
+
+=== Git in Powershell
+
+=== Git in Your Application
+
+==== libgit2
+
+==== libgit2sharp
+
+==== objective-git
+
+==== rugged
+
+==== pygit2

en/book/09-git-internals/chapter9.asc → en/book/11-git-internals/chapter11.asc

@@ -966,6 +966,8 @@ Let’s see how much space you saved.
 
 The packed repository size is down to 7K, which is much better than 2MB. You can see from the size value that the big object is still in your loose objects, so it’s not gone; but it won’t be transferred on a push or subsequent clone, which is what is important. If you really wanted to, you could remove the object completely by running `git prune --expire`.
 
+=== Environment Variables
+
 === Summary
 
 You should have a pretty good understanding of what Git does in the background and, to some degree, how it’s implemented. This chapter has covered a number of plumbing commands — commands that are lower level and simpler than the porcelain commands you’ve learned about in the rest of the book. Understanding how Git works at a lower level should make it easier to understand why it’s doing what it’s doing and also to write your own tools and helping scripts to make your specific workflow work for you.

en/book/book.asc

@@ -24,10 +24,14 @@ include::04-git-server/chapter4.asc[]
 
 include::05-distributed-git/chapter5.asc[]
 
-include::06-git-tools/chapter6.asc[]
+include::06-github/chapter6.asc[]
 
-include::07-customizing-git/chapter7.asc[]
+include::07-git-tools/chapter7.asc[]
 
-include::08-git-and-other-scms/chapter8.asc[]
+include::08-customizing-git/chapter8.asc[]
 
-include::09-git-internals/chapter9.asc[]
+include::09-git-and-other-scms/chapter9.asc[]
+
+include::10-git-in-other-environments/chapter10.asc[]
+
+include::11-git-internals/chapter11.asc[]