From 7a4a283105c6ac21fcd7df88cf6a698281c2cd19 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Sat, 7 Jul 2007 21:53:22 +0000 Subject: [PATCH] Autogenerated HTML docs for v1.5.3-rc0-63-gc956 --- config.txt | 5 +++++ core-intro.txt | 2 +- git-config.html | 12 +++++++++++- git-rerere.html | 6 +++--- git-rerere.txt | 4 ++-- git-submodule.html | 13 +++++++------ git-submodule.txt | 7 ++++--- git.html | 4 ++-- user-manual.html | 14 +++++++------- user-manual.txt | 14 +++++++------- 10 files changed, 49 insertions(+), 32 deletions(-) diff --git a/config.txt b/config.txt index 66a55b051..4b67f0adf 100644 --- a/config.txt +++ b/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/core-intro.txt b/core-intro.txt index eea44d9d5..f3cc2238c 100644 --- a/core-intro.txt +++ b/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/git-config.html b/git-config.html index eec0eef81..5e46547f9 100644 --- a/git-config.html +++ b/git-config.html @@ -1305,6 +1305,16 @@ gc.rerereunresolved

+rerere.enabled +
+
+

+ Activate recording of resolved conflicts, so that identical + conflict hunks can be resolved automatically, should they + be encountered again. See git-rerere(1). +

+
+
gitcvs.enabled
@@ -1829,7 +1839,7 @@ transfer.unpackLimit diff --git a/git-rerere.html b/git-rerere.html index 7caf338ce..408717023 100644 --- a/git-rerere.html +++ b/git-rerere.html @@ -289,7 +289,7 @@ 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. @@ -444,7 +444,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 actual merge later with updated master and topic branch, as long @@ -481,7 +481,7 @@ conflict.

diff --git a/git-rerere.txt b/git-rerere.txt index 7ff9b05e6..c4d426323 100644 --- a/git-rerere.txt +++ b/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/git-submodule.html b/git-submodule.html index b7243732e..7d587999f 100644 --- a/git-submodule.html +++ b/git-submodule.html @@ -272,8 +272,9 @@ git-submodule(1) Manual Page

SYNOPSIS

-

git-submodule [--quiet] [-b branch] add <repository> [<path>] -git-submodule [--quiet] [--cached] [status|init|update] [--] [<path>…]

+
+
git-submodule [--quiet] [-b branch] add <repository> [<path>] +git-submodule [--quiet] [--cached] [status|init|update] [--] [<path>…]

COMMANDS

@@ -310,8 +311,8 @@ 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.

@@ -372,7 +373,7 @@ update

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

@@ -384,7 +385,7 @@ to each submodule url is "module.$path.url".

diff --git a/git-submodule.txt b/git-submodule.txt index 7f0904e29..2c48936fc 100644 --- a/git-submodule.txt +++ b/git-submodule.txt @@ -8,6 +8,7 @@ git-submodule - Initialize, update or inspect submodules SYNOPSIS -------- +[verse] 'git-submodule' [--quiet] [-b branch] add [] 'git-submodule' [--quiet] [--cached] [status|init|update] [--] [...] @@ -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/git.html b/git.html index 427496174..b55f52c09 100644 --- a/git.html +++ b/git.html @@ -2301,7 +2301,7 @@ option, updates your working tree with the merge results for paths that have been trivially merged.

8) Merging multiple trees, continued

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 @@ -2398,7 +2398,7 @@ contributors on the git-list <git@vger.kernel.org>.

diff --git a/user-manual.html b/user-manual.html index e08c53150..0e605b607 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1246,13 +1246,13 @@ cache, and the normal operation is to re-generate it completely from a known tree object, or update/compare it with a live tree that is being 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.

The Workflow

Generally, all "git" operations work on the index file. Some operations +that it described.

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.

The Workflow

Generally, all "git" operations work on the index file. Some operations work purely on the index file (showing the current state of the index), but most operations move data to and from the index file. Either from the database or from the working directory. Thus there are four diff --git a/user-manual.txt b/user-manual.txt index ff7c71d4f..c23077c72 100644 --- a/user-manual.txt +++ b/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. -- 2.26.2