suggested in the previous section may be new to you. You do not\r
have to worry. git supports "shared public repository" style of\r
cooperation you are probably more familiar with as well.</p>\r
-<p>See <a href="cvs-migration.txt">git for CVS users</a> for the details.</p>\r
+<p>See <a href="cvs-migration.html">git for CVS users</a> for the details.</p>\r
</div>\r
<h2>Bundling your work together</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 15-Jul-2006 01:38:27 UTC\r
+Last updated 14-Sep-2006 07:38:12 UTC\r
</div>\r
</div>\r
</body>\r
have to worry. git supports "shared public repository" style of
cooperation you are probably more familiar with as well.
-See link:cvs-migration.txt[git for CVS users] for the details.
+See link:cvs-migration.html[git for CVS users] for the details.
Bundling your work together
---------------------------
<div class="sectionbody">\r
<p>Git allows you to specify scripts called "hooks" to be run at certain\r
points. You can use these, for example, to send all commits to the shared\r
-repository to a mailing list. See <a href="hooks.txt">Hooks used by git</a>.</p>\r
+repository to a mailing list. See <a href="hooks.html">Hooks used by git</a>.</p>\r
<p>You can enforce finer grained permissions using update hooks. See\r
<a href="howto/update-hook-example.txt">Controlling access to branches using\r
update hooks</a>.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 15-Jul-2006 01:38:29 UTC\r
+Last updated 14-Sep-2006 07:38:14 UTC\r
</div>\r
</div>\r
</body>\r
Git allows you to specify scripts called "hooks" to be run at certain
points. You can use these, for example, to send all commits to the shared
-repository to a mailing list. See link:hooks.txt[Hooks used by git].
+repository to a mailing list. See link:hooks.html[Hooks used by git].
You can enforce finer grained permissions using update hooks. See
link:howto/update-hook-example.txt[Controlling access to branches using
</dt>\r
<dd>\r
<p>\r
- When applying a patch, which is a git-enhanced patch\r
- that was prepared to record the pre- and post-image object\r
- name in full, and the path being patched exactly matches\r
- the object the patch applies to (i.e. "index" line's\r
- pre-image object name is what is in the working tree),\r
- and the post-image object is available in the object\r
- database, use the post-image object as the patch\r
- result. This allows binary files to be patched in a\r
- very limited way.\r
+ Historically we did not allow binary patch applied\r
+ without an explicit permission from the user, and this\r
+ flag was the way to do so. Currently we always allow binary\r
+ patch application, so this is a no-op.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 28-Aug-2006 07:18:32 UTC\r
+Last updated 14-Sep-2006 07:38:11 UTC\r
</div>\r
</div>\r
</body>\r
deletion part but not addition part.
--allow-binary-replacement, --binary::
- When applying a patch, which is a git-enhanced patch
- that was prepared to record the pre- and post-image object
- name in full, and the path being patched exactly matches
- the object the patch applies to (i.e. "index" line's
- pre-image object name is what is in the working tree),
- and the post-image object is available in the object
- database, use the post-image object as the patch
- result. This allows binary files to be patched in a
- very limited way.
+ Historically we did not allow binary patch applied
+ without an explicit permission from the user, and this
+ flag was the way to do so. Currently we always allow binary
+ patch application, so this is a no-op.
--exclude=<path-pattern>::
Don't apply changes to files matching the given path pattern. This can
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-unpack-objects</em> [-n] [-q] <pack-file</p>\r
+<p><em>git-unpack-objects</em> [-n] [-q] [-r] <pack-file</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
flag suppresses it.\r
</p>\r
</dd>\r
+<dt>\r
+-r\r
+</dt>\r
+<dd>\r
+<p>\r
+ When unpacking a corrupt packfile, the command dies at\r
+ the first corruption. This flag tells it to keep going\r
+ and make the best effort to recover as many objects as\r
+ possible.\r
+</p>\r
+</dd>\r
</dl>\r
</div>\r
<h2>Author</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 15-Jul-2006 01:38:18 UTC\r
+Last updated 14-Sep-2006 07:38:11 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-unpack-objects' [-n] [-q] <pack-file
+'git-unpack-objects' [-n] [-q] [-r] <pack-file
DESCRIPTION
The command usually shows percentage progress. This
flag suppresses it.
+-r::
+ When unpacking a corrupt packfile, the command dies at
+ the first corruption. This flag tells it to keep going
+ and make the best effort to recover as many objects as
+ possible.
+
Author
------
<p>In addition to being the staging area for new commits, the index file\r
is also populated from the object database when checking out a\r
branch, and is used to hold the trees involved in a merge operation.\r
-See the <a href="core-tutorial.txt">core tutorial</a> and the relevant man\r
+See the <a href="core-tutorial.html">core tutorial</a> and the relevant man\r
pages for details.</p>\r
</div>\r
<h2>What next?</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 10-Aug-2006 00:18:00 UTC\r
+Last updated 14-Sep-2006 07:38:12 UTC\r
</div>\r
</div>\r
</body>\r
In addition to being the staging area for new commits, the index file
is also populated from the object database when checking out a
branch, and is used to hold the trees involved in a merge operation.
-See the link:core-tutorial.txt[core tutorial] and the relevant man
+See the link:core-tutorial.html[core tutorial] and the relevant man
pages for details.
What next?