From: Junio C Hamano Date: Sun, 23 Mar 2008 09:41:37 +0000 (+0000) Subject: Autogenerated HTML docs for v1.5.5-rc1 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=25c0b703a31f4df8059a9f6c8a081d6a89ba22d9;p=git.git Autogenerated HTML docs for v1.5.5-rc1 --- diff --git a/RelNotes-1.5.5.txt b/RelNotes-1.5.5.txt index e31ae6a29..14beed49b 100644 --- a/RelNotes-1.5.5.txt +++ b/RelNotes-1.5.5.txt @@ -124,6 +124,9 @@ Updates since v1.5.4 * "git gc" now automatically prunes unreachable objects that are two weeks old or older. + * "git gc --auto" can be disabled more easily by just setting gc.auto + to zero. It also tolerates more packfiles by default. + * "git grep" now knows "--name-only" is a synonym for the "-l" option. * "git help " now reports "'git ' is alias to ", @@ -201,6 +204,6 @@ this release, unless otherwise noted. --- exec >/var/tmp/1 -O=v1.5.4.4-620-gc817faa +O=v1.5.5-rc1 echo O=`git describe refs/heads/master` git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint diff --git a/config.txt b/config.txt index 0865f4e01..3017d640c 100644 --- a/config.txt +++ b/config.txt @@ -582,7 +582,7 @@ gc.autopacklimit:: When there are more than this many packs that are not marked with `*.keep` file in the repository, `git gc --auto` consolidates them into one larger pack. The - default value is 20. Setting this to 0 disables it. + default value is 50. Setting this to 0 disables it. gc.packrefs:: `git gc` does not run `git pack-refs` in a bare repository by diff --git a/git-config.html b/git-config.html index 26628a873..29fc64cfe 100644 --- a/git-config.html +++ b/git-config.html @@ -1556,7 +1556,7 @@ gc.autopacklimit When there are more than this many packs that are not marked with *.keep file in the repository, git gc --auto consolidates them into one larger pack. The - default value is 20. Setting this to 0 disables it. + default value is 50. Setting this to 0 disables it.

@@ -2392,7 +2392,7 @@ web.browser diff --git a/git-fast-import.html b/git-fast-import.html index e9e38bd1b..36570ca62 100644 --- a/git-fast-import.html +++ b/git-fast-import.html @@ -705,6 +705,9 @@ new commit.

Omitting the from command in the first commit of a new branch will cause fast-import to create that commit with no ancestor. This tends to be desired only for the initial commit of a project. +If the frontend creates all files from scratch when making a new +branch, a merge command may be used instead of from to start +the commit with an empty tree. Omitting the from command on existing branches is usually desired, as the current commit on that branch is automatically assumed to be the first ancestor of the new commit.

@@ -755,13 +758,15 @@ fast-import to resolve the commit through Git's revision parsing library, rather than its internal branch table, thereby loading in the existing value of the branch.

merge

-

Includes one additional ancestor commit, and makes the current -commit a merge commit. An unlimited number of merge commands per +

Includes one additional ancestor commit. If the from command is +omitted when creating a new branch, the first merge commit will be +the first ancestor of the current commit, and the branch will start +out with no files. An unlimited number of merge commands per commit are permitted by fast-import, thereby establishing an n-way merge. However Git's other tools never create commits with more than 15 additional ancestors (forming a 16-way merge). For this reason it is suggested that frontends do not use more than 15 merge -commands per commit.

+commands per commit; 16, if starting a new, empty branch.

Here <committish> is any of the commit specification expressions also accepted by from (see above).

filemodify

@@ -1411,7 +1416,7 @@ memory footprint (less than 2.7 MiB per active branch).

diff --git a/git-fast-import.txt b/git-fast-import.txt index 96f676707..c29a4f812 100644 --- a/git-fast-import.txt +++ b/git-fast-import.txt @@ -385,6 +385,9 @@ new commit. Omitting the `from` command in the first commit of a new branch will cause fast-import to create that commit with no ancestor. This tends to be desired only for the initial commit of a project. +If the frontend creates all files from scratch when making a new +branch, a `merge` command may be used instead of `from` to start +the commit with an empty tree. Omitting the `from` command on existing branches is usually desired, as the current commit on that branch is automatically assumed to be the first ancestor of the new commit. @@ -427,13 +430,15 @@ existing value of the branch. `merge` ^^^^^^^ -Includes one additional ancestor commit, and makes the current -commit a merge commit. An unlimited number of `merge` commands per +Includes one additional ancestor commit. If the `from` command is +omitted when creating a new branch, the first `merge` commit will be +the first ancestor of the current commit, and the branch will start +out with no files. An unlimited number of `merge` commands per commit are permitted by fast-import, thereby establishing an n-way merge. However Git's other tools never create commits with more than 15 additional ancestors (forming a 16-way merge). For this reason it is suggested that frontends do not use more than 15 `merge` -commands per commit. +commands per commit; 16, if starting a new, empty branch. Here `` is any of the commit specification expressions also accepted by `from` (see above). diff --git a/git-filter-branch.html b/git-filter-branch.html index c8d3323d3..42ad7f297 100644 --- a/git-filter-branch.html +++ b/git-filter-branch.html @@ -289,7 +289,7 @@ a perl rewrite on all files) or information about each commit. Otherwise, all information (including original commit times or merge information) will be preserved.

The command will only rewrite the _positive_ refs mentioned in the -command line (i.e. if you pass a..b, only b will be rewritten). +command line (e.g. if you pass a..b, only b will be rewritten). If you specify no filters, the commits will be recommitted without any changes, which would normally have no effect. Nevertheless, this may be useful in the future for compensating for some git bugs or such, @@ -303,19 +303,20 @@ would suffice to fix your problem.

Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace refs/original/.

-

Note that since this operation is extensively I/O expensive, it might +

Note that since this operation is very I/O expensive, it might be a good idea to redirect the temporary directory off-disk with the -d option, e.g. on tmpfs. Reportedly the speedup is very noticeable.

Filters

The filters are applied in the order as listed below. The <command> -argument is always evaluated in shell using the eval command (with the -notable exception of the commit filter, for technical reasons). +argument is always evaluated in the shell context using the eval command +(with the notable exception of the commit filter, for technical reasons). Prior to that, the $GIT_COMMIT environment variable will be set to contain the id of the commit being rewritten. Also, GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, -and GIT_COMMITTER_DATE are set according to the current commit. If any -evaluation of <command> returns a non-zero exit status, the whole operation -will be aborted.

+and GIT_COMMITTER_DATE are set according to the current commit. The values +of these variables after the filters have run, are used for the new commit. +If any evaluation of <command> returns a non-zero exit status, the whole +operation will be aborted.

A map function is available that takes an "original sha1 id" argument and outputs a "rewritten sha1 id" if the commit has been already rewritten, and "original sha1 id" otherwise; the map function can @@ -330,9 +331,9 @@ multiple commits.

- This is the filter for modifying the environment in which - the commit will be performed. Specifically, you might want - to rewrite the author/committer name/email/time environment + This filter may be used if you only need to modify the environment + in which the commit will be performed. Specifically, you might + want to rewrite the author/committer name/email/time environment variables (see git-commit(1) for details). Do not forget to re-export the variables.

@@ -449,7 +450,7 @@ definition impossible to preserve signatures at any rate.)

Use this option to set the path to the temporary directory used for rewriting. When applying a tree filter, the command needs to - temporary checkout the tree to some directory, which may consume + temporarily check out the tree to some directory, which may consume considerable space in case of large projects. By default it does this in the .git-rewrite/ directory but you can override that choice by this parameter. @@ -604,7 +605,7 @@ and the git list <git@vger.kernel.org>

diff --git a/git-filter-branch.txt b/git-filter-branch.txt index 543a1cf10..2a78549be 100644 --- a/git-filter-branch.txt +++ b/git-filter-branch.txt @@ -25,7 +25,7 @@ Otherwise, all information (including original commit times or merge information) will be preserved. The command will only rewrite the _positive_ refs mentioned in the -command line (i.e. if you pass 'a..b', only 'b' will be rewritten). +command line (e.g. if you pass 'a..b', only 'b' will be rewritten). If you specify no filters, the commits will be recommitted without any changes, which would normally have no effect. Nevertheless, this may be useful in the future for compensating for some git bugs or such, @@ -42,7 +42,7 @@ Always verify that the rewritten version is correct: The original refs, if different from the rewritten ones, will be stored in the namespace 'refs/original/'. -Note that since this operation is extensively I/O expensive, it might +Note that since this operation is very I/O expensive, it might be a good idea to redirect the temporary directory off-disk with the '-d' option, e.g. on tmpfs. Reportedly the speedup is very noticeable. @@ -51,14 +51,15 @@ Filters ~~~~~~~ The filters are applied in the order as listed below. The -argument is always evaluated in shell using the 'eval' command (with the -notable exception of the commit filter, for technical reasons). +argument is always evaluated in the shell context using the 'eval' command +(with the notable exception of the commit filter, for technical reasons). Prior to that, the $GIT_COMMIT environment variable will be set to contain the id of the commit being rewritten. Also, GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, -and GIT_COMMITTER_DATE are set according to the current commit. If any -evaluation of returns a non-zero exit status, the whole operation -will be aborted. +and GIT_COMMITTER_DATE are set according to the current commit. The values +of these variables after the filters have run, are used for the new commit. +If any evaluation of returns a non-zero exit status, the whole +operation will be aborted. A 'map' function is available that takes an "original sha1 id" argument and outputs a "rewritten sha1 id" if the commit has been already @@ -71,9 +72,9 @@ OPTIONS ------- --env-filter :: - This is the filter for modifying the environment in which - the commit will be performed. Specifically, you might want - to rewrite the author/committer name/email/time environment + This filter may be used if you only need to modify the environment + in which the commit will be performed. Specifically, you might + want to rewrite the author/committer name/email/time environment variables (see linkgit:git-commit[1] for details). Do not forget to re-export the variables. @@ -149,7 +150,7 @@ definition impossible to preserve signatures at any rate.) -d :: Use this option to set the path to the temporary directory used for rewriting. When applying a tree filter, the command needs to - temporary checkout the tree to some directory, which may consume + temporarily check out the tree to some directory, which may consume considerable space in case of large projects. By default it does this in the '.git-rewrite/' directory but you can override that choice by this parameter.