summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/config.txt5
-rw-r--r--Documentation/core-intro.txt2
-rw-r--r--Documentation/git-rerere.txt4
-rw-r--r--Documentation/git-submodule.txt7
-rw-r--r--Documentation/user-manual.txt14
5 files changed, 19 insertions, 13 deletions
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 66a55b0514..4b67f0adf7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -448,6 +448,11 @@ gc.rerereunresolved::
kept for this many days when `git rerere gc` is run.
The default is 15 days. See gitlink:git-rerere[1].
+rerere.enabled::
+ Activate recording of resolved conflicts, so that identical
+ conflict hunks can be resolved automatically, should they
+ be encountered again. See gitlink:git-rerere[1].
+
gitcvs.enabled::
Whether the cvs server interface is enabled for this repository.
See gitlink:git-cvsserver[1].
diff --git a/Documentation/core-intro.txt b/Documentation/core-intro.txt
index eea44d9d56..f3cc2238c7 100644
--- a/Documentation/core-intro.txt
+++ b/Documentation/core-intro.txt
@@ -528,7 +528,7 @@ paths that have been trivially merged.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index 7ff9b05e68..c4d4263238 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -23,7 +23,7 @@ initial manual merge, and later by noticing the same automerge
results and applying the previously recorded hand resolution.
[NOTE]
-You need to create `$GIT_DIR/rr-cache` directory to enable this
+You need to set the config variable rerere.enabled to enable this
command.
@@ -171,7 +171,7 @@ records it if it is a new conflict, or reuses the earlier hand
resolve when it is not. `git-commit` also invokes `git-rerere`
when recording a merge result. What this means is that you do
not have to do anything special yourself (Note: you still have
-to create `$GIT_DIR/rr-cache` directory to enable this command).
+to set the config variable rerere.enabled to enable this command).
In our example, when you did the test merge, the manual
resolution is recorded, and it will be reused when you do the
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 7f0904e293..2c48936fcd 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -8,6 +8,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
+[verse]
'git-submodule' [--quiet] [-b branch] add <repository> [<path>]
'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
@@ -32,8 +33,8 @@ status::
init::
Initialize the submodules, i.e. register in .git/config each submodule
- path and url found in .gitmodules. The key used in git/config is
- `submodule.$path.url`. This command does not alter existing information
+ name and url found in .gitmodules. The key used in .git/config is
+ `submodule.$name.url`. This command does not alter existing information
in .git/config.
update::
@@ -64,7 +65,7 @@ FILES
When initializing submodules, a .gitmodules file in the top-level directory
of the containing repository is used to find the url of each submodule.
This file should be formatted in the same way as $GIR_DIR/config. The key
-to each submodule url is "module.$path.url".
+to each submodule url is "submodule.$name.url".
AUTHOR
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ff7c71d4fb..c23077c724 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2957,13 +2957,13 @@ developed. If you blow the directory cache away entirely, you generally
haven't lost any information as long as you have the name of the tree
that it described.
-At the same time, the index is at the same time also the
-staging area for creating new trees, and creating a new tree always
-involves a controlled modification of the index file. In particular,
-the index file can have the representation of an intermediate tree that
-has not yet been instantiated. So the index can be thought of as a
-write-back cache, which can contain dirty information that has not yet
-been written back to the backing store.
+At the same time, the index is also the staging area for creating
+new trees, and creating a new tree always involves a controlled
+modification of the index file. In particular, the index file can
+have the representation of an intermediate tree that has not yet been
+instantiated. So the index can be thought of as a write-back cache,
+which can contain dirty information that has not yet been written back
+to the backing store.