+ Files to be committed. The meaning of these is
+ different between `--include` and `--only`. Without
+ either, it defaults `--only` semantics.
+
+If you make a commit and then found a mistake immediately after
+that, you can recover from it with gitlink:git-reset[1].
+
+
+Discussion
+----------
+
+`git commit` without _any_ parameter commits the tree structure
+recorded by the current index file. This is a whole-tree commit
+even the command is invoked from a subdirectory.
+
+`git commit --include paths...` is equivalent to
+
+ git update-index --remove paths...
+ git commit
+
+That is, update the specified paths to the index and then commit
+the whole tree.
+
+`git commit paths...` largely bypasses the index file and
+commits only the changes made to the specified paths. It has
+however several safety valves to prevent confusion.
+
+. It refuses to run during a merge (i.e. when
+ `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
+ that the traditional semantics now needs -i flag.
+
+. It refuses to run if named `paths...` are different in HEAD
+ and the index (ditto about reminding). Added paths are OK.
+ This is because an earlier `git diff` (not `git diff HEAD`)
+ would have shown the differences since the last `git
+ update-index paths...` to the user, and an inexperienced user
+ may mistakenly think that the changes between the index and
+ the HEAD (i.e. earlier changes made before the last `git
+ update-index paths...` was done) are not being committed.
+
+. It reads HEAD commit into a temporary index file, updates the
+ specified `paths...` and makes a commit. At the same time,
+ the real index file is also updated with the same `paths...`.
+
+`git commit --all` updates the index file with _all_ changes to
+the working tree, and makes a whole-tree commit, regardless of
+which subdirectory the command is invoked in.