path: root/Documentation/tutorial.txt
diff options
authorNicolas Pitre <>2006-12-04 16:13:39 (GMT)
committerJunio C Hamano <>2006-12-05 00:33:51 (GMT)
commit366bfcb68f4d98a43faaf17893a1aa0a7a9e2c58 (patch)
tree70d87fdba82ccf99095148a4918a77e019d12891 /Documentation/tutorial.txt
parentba988a83f0cfdafdcfdc7ed44253840ea83578fb (diff)
make 'git add' a first class user friendly interface to the index
This brings the power of the index up front using a proper mental model without talking about the index at all. See for example how all the technical discussion has been evacuated from the git-add man page. Any content to be committed must be added together. Whether that content comes from new files or modified files doesn't matter. You just need to "add" it, either with git-add, or by providing git-commit with -a (for already known files only of course). No need for a separate command to distinguish new vs modified files please. That would only screw the mental model everybody should have when using GIT. Signed-off-by: Nicolas Pitre <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'Documentation/tutorial.txt')
1 files changed, 40 insertions, 6 deletions
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index fe4491d..02dede3 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -87,14 +87,48 @@ thorough description. Tools that turn commits into email, for
example, use the first line on the Subject line and the rest of the
commit in the body.
-To add a new file, first create the file, then
-$ git add path/to/new/file
+Git tracks content not files
+With git you have to explicitly "add" all the changed _content_ you
+want to commit together. This can be done in a few different ways:
+1) By using 'git add <file_spec>...'
+ This can be performed multiple times before a commit. Note that this
+ is not only for adding new files. Even modified files must be
+ added to the set of changes about to be committed. The "git status"
+ command gives you a summary of what is included so far for the
+ next commit. When done you should use the 'git commit' command to
+ make it real.
+ Note: don't forget to 'add' a file again if you modified it after the
+ first 'add' and before 'commit'. Otherwise only the previous added
+ state of that file will be committed. This is because git tracks
+ content, so what you're really 'add'ing to the commit is the *content*
+ of the file in the state it is in when you 'add' it.
+2) By using 'git commit -a' directly
+ This is a quick way to automatically 'add' the content from all files
+ that were modified since the previous commit, and perform the actual
+ commit without having to separately 'add' them beforehand. This will
+ not add content from new files i.e. files that were never added before.
+ Those files still have to be added explicitly before performing a
+ commit.
+But here's a twist. If you do 'git commit <file1> <file2> ...' then only
+the changes belonging to those explicitly specified files will be
+committed, entirely bypassing the current "added" changes. Those "added"
+changes will still remain available for a subsequent commit though.
+However, for normal usage you only have to remember 'git add' + 'git commit'
+and/or 'git commit -a'.
-then commit as usual. No special command is required when removing a
-file; just remove it, then tell `commit` about the file as usual.
+Viewing the changelog
At any point you can view the history of your changes using