From 3cdb38519cf9ac94b20b9eba6e4195f7e7674de7 Mon Sep 17 00:00:00 2001 From: Holger Weiss Date: Sat, 11 Jan 2014 22:45:56 +0100 Subject: doc/faq/git.md: Add clarifications regarding index Clarify the purpose of the staging area, and (try to) improve the "Basic Concepts" section in another few ways. diff --git a/web/input/doc/faq/git.md b/web/input/doc/faq/git.md index 71200c8..53260ec 100644 --- a/web/input/doc/faq/git.md +++ b/web/input/doc/faq/git.md @@ -15,23 +15,26 @@ we can’t have a central shared Git repository (and we indeed have one), this means distributed development can occur around that central repository. Git has an additional stage between the working directory and the repository. -When you want to add files or changes, you use -**git add**. This adds the changes to the repository index, which can be seen -as a staging area. When you commit with **git commit**, only the changes in -the index are considered. After committing, the changes are still local. To -share it with others, you have to push it to a remote repository, or gave -someone pull from your publicly accessible repository (in most case you will -still have to push changes there, unless if you were running a git daemon -straight off your working repository). - -Finally you can’t miss the fact that -there is no more revision numbers, and the distributed nature of Git is the -reason for that: there is absolutely no way a single number could be tracked -in a distributed way. Instead Git uses SHA1 hashes to identify commits (as -well as other objects in the repository). Each branch and tag refer to an -object name (SHA1 hash), and each commits have one or more parents (commit -objects). Although SHA1 hashes are 40 digits long, with Git you only have to -type a handful of digits to reference one. +The idea is that you might be working on multiple unrelated things without +wanting to commit all changes in one go. Therefore, the changes that should +be committed must first be added to the repository *index*, which can be seen +as a staging area. This is usually done with **git add**, both for new files +*and* for changes to existing ones. When you commit using **git commit**, +only the changes in the index are considered. + +After committing, the changes are still local. To share them with others, you +have to push them to a remote repository, or have someone pull from your +publicly accessible repository (in most cases you will still have to push +changes there, unless if you were running a git daemon straight off your +working repository). + +Finally, you can’t miss the fact that there are no revision numbers, and the +distributed nature of Git is the reason for that: there is absolutely no way a +single number could be tracked in a distributed way. Instead, Git uses SHA1 +hashes to identify commits (as well as other objects in the repository). Each +branch and tag refer to an object name (SHA1 hash), and each commits have one +or more parents (commit objects). Although SHA1 hashes are 40 digits long, +with Git you only have to type a handful of digits to reference one. ## Cloning a Project -- cgit v0.10-9-g596f