* "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 <alias>" now reports "'git <alias>' is alias to <what>",
---
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
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
When there are more than this many packs that are not\r
marked with <tt>*.keep</tt> file in the repository, <tt>git gc\r
--auto</tt> consolidates them into one larger pack. The\r
- default value is 20. Setting this to 0 disables it.\r
+ default value is 50. Setting this to 0 disables it.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 15-Mar-2008 09:48:17 UTC\r
+Last updated 23-Mar-2008 09:40:37 UTC\r
</div>\r
</div>\r
</body>\r
<p>Omitting the <tt>from</tt> command in the first commit of a new branch\r
will cause fast-import to create that commit with no ancestor. This\r
tends to be desired only for the initial commit of a project.\r
+If the frontend creates all files from scratch when making a new\r
+branch, a <tt>merge</tt> command may be used instead of <tt>from</tt> to start\r
+the commit with an empty tree.\r
Omitting the <tt>from</tt> command on existing branches is usually desired,\r
as the current commit on that branch is automatically assumed to\r
be the first ancestor of the new commit.</p>\r
rather than its internal branch table, thereby loading in the\r
existing value of the branch.</p>\r
<h4><tt>merge</tt></h4>\r
-<p>Includes one additional ancestor commit, and makes the current\r
-commit a merge commit. An unlimited number of <tt>merge</tt> commands per\r
+<p>Includes one additional ancestor commit. If the <tt>from</tt> command is\r
+omitted when creating a new branch, the first <tt>merge</tt> commit will be\r
+the first ancestor of the current commit, and the branch will start\r
+out with no files. An unlimited number of <tt>merge</tt> commands per\r
commit are permitted by fast-import, thereby establishing an n-way merge.\r
However Git's other tools never create commits with more than 15\r
additional ancestors (forming a 16-way merge). For this reason\r
it is suggested that frontends do not use more than 15 <tt>merge</tt>\r
-commands per commit.</p>\r
+commands per commit; 16, if starting a new, empty branch.</p>\r
<p>Here <tt><committish></tt> is any of the commit specification expressions\r
also accepted by <tt>from</tt> (see above).</p>\r
<h4><tt>filemodify</tt></h4>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Feb-2008 10:02:22 UTC\r
+Last updated 23-Mar-2008 09:40:37 UTC\r
</div>\r
</div>\r
</body>\r
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.
`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).
Otherwise, all information (including original commit times or merge\r
information) will be preserved.</p>\r
<p>The command will only rewrite the _positive_ refs mentioned in the\r
-command line (i.e. if you pass <em>a..b</em>, only <em>b</em> will be rewritten).\r
+command line (e.g. if you pass <em>a..b</em>, only <em>b</em> will be rewritten).\r
If you specify no filters, the commits will be recommitted without any\r
changes, which would normally have no effect. Nevertheless, this may be\r
useful in the future for compensating for some git bugs or such,\r
<p>Always verify that the rewritten version is correct: The original refs,\r
if different from the rewritten ones, will be stored in the namespace\r
<em>refs/original/</em>.</p>\r
-<p>Note that since this operation is extensively I/O expensive, it might\r
+<p>Note that since this operation is very I/O expensive, it might\r
be a good idea to redirect the temporary directory off-disk with the\r
<em>-d</em> option, e.g. on tmpfs. Reportedly the speedup is very noticeable.</p>\r
<h3>Filters</h3>\r
<p>The filters are applied in the order as listed below. The <command>\r
-argument is always evaluated in shell using the <em>eval</em> command (with the\r
-notable exception of the commit filter, for technical reasons).\r
+argument is always evaluated in the shell context using the <em>eval</em> command\r
+(with the notable exception of the commit filter, for technical reasons).\r
Prior to that, the $GIT_COMMIT environment variable will be set to contain\r
the id of the commit being rewritten. Also, GIT_AUTHOR_NAME,\r
GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,\r
-and GIT_COMMITTER_DATE are set according to the current commit. If any\r
-evaluation of <command> returns a non-zero exit status, the whole operation\r
-will be aborted.</p>\r
+and GIT_COMMITTER_DATE are set according to the current commit. The values\r
+of these variables after the filters have run, are used for the new commit.\r
+If any evaluation of <command> returns a non-zero exit status, the whole\r
+operation will be aborted.</p>\r
<p>A <em>map</em> function is available that takes an "original sha1 id" argument\r
and outputs a "rewritten sha1 id" if the commit has been already\r
rewritten, and "original sha1 id" otherwise; the <em>map</em> function can\r
</dt>\r
<dd>\r
<p>\r
- This is the filter for modifying the environment in which\r
- the commit will be performed. Specifically, you might want\r
- to rewrite the author/committer name/email/time environment\r
+ This filter may be used if you only need to modify the environment\r
+ in which the commit will be performed. Specifically, you might\r
+ want to rewrite the author/committer name/email/time environment\r
variables (see <a href="git-commit.html">git-commit(1)</a> for details). Do not forget\r
to re-export the variables.\r
</p>\r
<p>\r
Use this option to set the path to the temporary directory used for\r
rewriting. When applying a tree filter, the command needs to\r
- temporary checkout the tree to some directory, which may consume\r
+ temporarily check out the tree to some directory, which may consume\r
considerable space in case of large projects. By default it\r
does this in the <em>.git-rewrite/</em> directory but you can override\r
that choice by this parameter.\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 26-Feb-2008 09:16:45 UTC\r
+Last updated 23-Mar-2008 09:40:59 UTC\r
</div>\r
</div>\r
</body>\r
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,
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.
~~~~~~~
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
-------
--env-filter <command>::
- 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.
-d <directory>::
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.