* Documentation updates
- Clarifications and corrections to 1.5.0 release notes.
+
- The main documentation did not link to git-remote documentation.
+ - Clarified introductory text of git-rebase documentation.
+
+ - Converted remaining mentions of update-index on Porcelain
+ documents to git-add/git-rm.
+
* Bugfixes
- git-daemon marks the listening sockets with FD_CLOEXEC so
that it won't be leaked into the children.
+ - segfault from git-blame when the mandatory pathname
+ parameter was missing was fixed; usage() message is given
+ instead.
+
+* Tweaks
+
+ - sliding mmap() inefficiently mmaped the same region of a
+ packfile with an access pattern that used objects in the
+ reverse order. This has been made more efficient.
+
--
-O=v1.5.0-7-g37b73cf
+exec >/var/tmp/1
+O=v1.5.0-24-g460ca30
echo O=`git describe maint`
-git shortlog --no-merges $O..
+git shortlog --no-merges $O..maint
- "git diff" learned --ignore-space-at-eol. This is a weaker
form of --ignore-space-change.
+ - "git name-rev" learned --refs=<pattern>, to limit the tags
+ used for naming the given revisions only to the ones
+ matching the given pattern.
+
* Updated behaviour of existing commands.
- - "git diff" outputs a trailing HT when pathnames have embedded
- SP on +++/--- header lines, in order to help "GNU patch" to
- parse its output. "git apply" was already updated to accept
- this modified output format since ce74618d (Sep 22, 2006).
+ - "git diff" outputs a trailing HT when pathnames have embedded
+ SP on +++/--- header lines, in order to help "GNU patch" to
+ parse its output. "git apply" was already updated to accept
+ this modified output format since ce74618d (Sep 22, 2006).
* Hooks
- - The sample update hook to show how to send out notification
- e-mail was updated to show only new commits that appeared in
- the repository. Earlier, it showed new commits that appeared
- on the branch.
+ - The sample update hook to show how to send out notification
+ e-mail was updated to show only new commits that appeared in
+ the repository. Earlier, it showed new commits that appeared
+ on the branch.
--
-O=v1.5.0-20-ga44a0c9
+exec >/var/tmp/1
+O=v1.5.0-49-g69bc0e2
echo O=`git describe master`
-git shortlog --no-merges $O..
+git shortlog --no-merges $O..master ^maint
file is associated with in any way.
A blob is typically created when gitlink:git-update-index[1]
-is run, and its data can be accessed by gitlink:git-cat-file[1].
+(or gitlink:git-add[1]) is run, and its data can be accessed by
+gitlink:git-cat-file[1].
Tree Object
~~~~~~~~~~~
</p>\r
<p>When a merge conflict happens, the index entries for conflicting\r
paths are left unmerged, and you need to resolve the conflicts\r
-and mark the resolved paths with <tt>git update-index</tt>.</p>\r
+and mark the resolved paths with <tt>git add</tt> (or <tt>git rm</tt> if the merge\r
+should result in deletion of the path).</p>\r
</dd>\r
<dt>\r
<new_branch>\r
<p>At this point, <tt>git diff</tt> shows the changes cleanly merged as in\r
the previous example, as well as the changes in the conflicted\r
files. Edit and resolve the conflict and mark it resolved with\r
-<tt>git update-index</tt> as usual:</p>\r
+<tt>git add</tt> as usual:</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ edit frotz\r
-$ git update-index frotz</tt></pre>\r
+$ git add frotz</tt></pre>\r
</div></div>\r
</li>\r
</ol>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 13-Feb-2007 23:48:05 UTC\r
+Last updated 18-Feb-2007 00:34:40 UTC\r
</div>\r
</div>\r
</body>\r
+
When a merge conflict happens, the index entries for conflicting
paths are left unmerged, and you need to resolve the conflicts
-and mark the resolved paths with `git update-index`.
+and mark the resolved paths with `git add` (or `git rm` if the merge
+should result in deletion of the path).
<new_branch>::
Name for the new branch.
At this point, `git diff` shows the changes cleanly merged as in
the previous example, as well as the changes in the conflicted
files. Edit and resolve the conflict and mark it resolved with
-`git update-index` as usual:
+`git add` as usual:
+
------------
$ edit frotz
-$ git update-index frotz
+$ git add frotz
------------
<p>\r
Resolve the conflicts. <tt>git-diff</tt> would report only the\r
conflicting paths because of the above 2. and 3.. Edit the\r
- working tree files into a desirable shape, <tt>git-update-index</tt>\r
+ working tree files into a desirable shape, <tt>git-add</tt> or <tt>git-rm</tt>\r
them, to make the index file contain what the merge result\r
should be, and run <tt>git-commit</tt> to commit the result.\r
</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 13-Feb-2007 05:16:09 UTC\r
+Last updated 18-Feb-2007 00:34:41 UTC\r
</div>\r
</div>\r
</body>\r
* Resolve the conflicts. `git-diff` would report only the
conflicting paths because of the above 2. and 3.. Edit the
- working tree files into a desirable shape, `git-update-index`
+ working tree files into a desirable shape, `git-add` or `git-rm`
them, to make the index file contain what the merge result
should be, and run `git-commit` to commit the result.
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-name-rev</em> [--tags] ( --all | --stdin | <committish>… )</p>\r
+<p><em>git-name-rev</em> [--tags] [--refs=<pattern>]\r
+ ( --all | --stdin | <committish>… )</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</p>\r
</dd>\r
<dt>\r
+--refs=<pattern>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Only use refs whose names match a given shell pattern.\r
+</p>\r
+</dd>\r
+<dt>\r
--all\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2006 08:41:15 UTC\r
+Last updated 18-Feb-2007 00:34:41 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-name-rev' [--tags] ( --all | --stdin | <committish>... )
+'git-name-rev' [--tags] [--refs=<pattern>]
+ ( --all | --stdin | <committish>... )
DESCRIPTION
-----------
--tags::
Do not use branch names, but only tags to name the commits
+--refs=<pattern>::
+ Only use refs whose names match a given shell pattern.
+
--all::
List all commits reachable from all refs
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
-<p>git-rebase replaces <branch> with a new branch of the same name. When\r
-the --onto option is provided the new branch starts out with a HEAD equal\r
-to <newbase>, otherwise it is equal to <upstream>. It then attempts to\r
-create a new commit for each commit from the original <branch> that does\r
-not exist in the <upstream> branch.</p>\r
+<p>If <branch> is specified, git-rebase will perform an automatic\r
+<tt>git checkout <branch></tt> before doing anything else. Otherwise\r
+it remains on the current branch.</p>\r
+<p>All changes made by commits in the current branch but that are not\r
+in <upstream> are saved to a temporary area. This is the same set\r
+of commits that would be shown by <tt>git log <upstream>..HEAD</tt>.</p>\r
+<p>The current branch is reset to <upstream>, or <newbase> if the\r
+--onto option was supplied. This has the exact same effect as\r
+<tt>git reset --hard <upstream></tt> (or <newbase>).</p>\r
+<p>The commits that were previously saved into the temporary area are\r
+then reapplied to the current branch, one by one, in order.</p>\r
<p>It is possible that a merge failure will prevent this process from being\r
completely automatic. You will have to resolve any such merge failure\r
and run <tt>git rebase --continue</tt>. Another option is to bypass the commit\r
that caused the merge failure with <tt>git rebase --skip</tt>. To restore the\r
original <branch> and remove the .dotest working files, use the command\r
<tt>git rebase --abort</tt> instead.</p>\r
-<p>Note that if <branch> is not specified on the command line, the currently\r
-checked out branch is used.</p>\r
<p>Assume the following history exists and the current branch is "topic":</p>\r
<div class="listingblock">\r
<div class="content">\r
typically this would be done with</p>\r
<div class="literalblock">\r
<div class="content">\r
-<pre><tt>git update-index <filename></tt></pre>\r
+<pre><tt>git add <filename></tt></pre>\r
</div></div>\r
<p>After resolving the conflict manually and updating the index with the\r
desired resolution, you can continue the rebasing process with</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 12-Feb-2007 07:15:21 UTC\r
+Last updated 18-Feb-2007 00:34:42 UTC\r
</div>\r
</div>\r
</body>\r
DESCRIPTION
-----------
-git-rebase replaces <branch> with a new branch of the same name. When
-the --onto option is provided the new branch starts out with a HEAD equal
-to <newbase>, otherwise it is equal to <upstream>. It then attempts to
-create a new commit for each commit from the original <branch> that does
-not exist in the <upstream> branch.
+If <branch> is specified, git-rebase will perform an automatic
+`git checkout <branch>` before doing anything else. Otherwise
+it remains on the current branch.
+
+All changes made by commits in the current branch but that are not
+in <upstream> are saved to a temporary area. This is the same set
+of commits that would be shown by `git log <upstream>..HEAD`.
+
+The current branch is reset to <upstream>, or <newbase> if the
+--onto option was supplied. This has the exact same effect as
+`git reset --hard <upstream>` (or <newbase>).
+
+The commits that were previously saved into the temporary area are
+then reapplied to the current branch, one by one, in order.
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
original <branch> and remove the .dotest working files, use the command
`git rebase --abort` instead.
-Note that if <branch> is not specified on the command line, the currently
-checked out branch is used.
-
Assume the following history exists and the current branch is "topic":
------------
typically this would be done with
- git update-index <filename>
+ git add <filename>
After resolving the conflict manually and updating the index with the
out to your working tree file, so you would not have to manually\r
resolve it. Note that <tt>git-rerere</tt> leaves the index file alone,\r
so you still need to do the final sanity checks with <tt>git diff</tt>\r
-(or <tt>git diff -c</tt>) and <tt>git update-index</tt> when you are\r
-satisfied.</p>\r
+(or <tt>git diff -c</tt>) and <tt>git add</tt> when you are satisfied.</p>\r
<p>As a convenience measure, <tt>git-merge</tt> automatically invokes\r
<tt>git-rerere</tt> when it exits with a failed automerge, which\r
records it if it is a new conflict, or reuses the earlier hand\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jan-2007 00:37:32 UTC\r
+Last updated 18-Feb-2007 00:34:42 UTC\r
</div>\r
</div>\r
</body>\r
out to your working tree file, so you would not have to manually
resolve it. Note that `git-rerere` leaves the index file alone,
so you still need to do the final sanity checks with `git diff`
-(or `git diff -c`) and `git update-index` when you are
-satisfied.
+(or `git diff -c`) and `git add` when you are satisfied.
As a convenience measure, `git-merge` automatically invokes
`git-rerere` when it exits with a failed automerge, which
</ol>\r
</dd>\r
<dt>\r
-Undo update-index\r
+Undo add\r
</dt>\r
<dd>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ edit <b>(1)</b>\r
-$ git-update-index frotz.c filfre.c\r
+$ git add frotz.c filfre.c\r
$ mailx <b>(2)</b>\r
$ git reset <b>(3)</b>\r
$ git pull git://info.example.com/ nitfol <b>(4)</b></tt></pre>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 15-Jan-2007 06:12:34 UTC\r
+Last updated 18-Feb-2007 00:34:43 UTC\r
</div>\r
</div>\r
</body>\r
<2> Rewind the master branch to get rid of those three commits.
<3> Switch to "topic/wip" branch and keep working.
-Undo update-index::
+Undo add::
+
------------
$ edit <1>
-$ git-update-index frotz.c filfre.c
+$ git add frotz.c filfre.c
$ mailx <2>
$ git reset <3>
$ git pull git://info.example.com/ nitfol <4>
<p>Examines paths in the working tree that has changes unrecorded\r
to the index file, and changes between the index file and the\r
current HEAD commit. The former paths are what you _could_\r
-commit by running <em>git-update-index</em> before running <em>git\r
+commit by running <em>git add</em> (or <em>git rm</em> if you are deleting) before running <em>git\r
commit</em>, and the latter paths are what you _would_ commit by\r
running <em>git commit</em>.</p>\r
<p>If there is no path that is different between the index file and\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 18-Nov-2006 22:17:48 UTC\r
+Last updated 18-Feb-2007 00:34:43 UTC\r
</div>\r
</div>\r
</body>\r
Examines paths in the working tree that has changes unrecorded
to the index file, and changes between the index file and the
current HEAD commit. The former paths are what you _could_
-commit by running 'git-update-index' before running 'git
+commit by running 'git add' (or 'git rm' if you are deleting) before running 'git
commit', and the latter paths are what you _would_ commit by
running 'git commit'.
<p>Examines paths in the working tree that has changes unrecorded\r
to the index file, and changes between the index file and the\r
current HEAD commit. The former paths are what you _could_\r
-commit by running <em>git-update-index</em> before running <em>git\r
+commit by running <em>git add</em> before running <em>git\r
commit</em>, and the latter paths are what you _would_ commit by\r
running <em>git commit</em>.</p>\r
<p>If there is no path that is different between the index file and\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jan-2007 00:37:34 UTC\r
+Last updated 18-Feb-2007 00:34:44 UTC\r
</div>\r
</div>\r
</body>\r
Examines paths in the working tree that has changes unrecorded
to the index file, and changes between the index file and the
current HEAD commit. The former paths are what you _could_
-commit by running 'git-update-index' before running 'git
+commit by running 'git add' before running 'git
commit', and the latter paths are what you _would_ commit by
running 'git commit'.
directory tree, and renaming a file does not change the object that\r
file is associated with in any way.</p>\r
<p>A blob is typically created when <a href="git-update-index.html">git-update-index(1)</a>\r
-is run, and its data can be accessed by <a href="git-cat-file.html">git-cat-file(1)</a>.</p>\r
+(or <a href="git-add.html">git-add(1)</a>) is run, and its data can be accessed by\r
+<a href="git-cat-file.html">git-cat-file(1)</a>.</p>\r
<h3>Tree Object</h3>\r
<p>The next hierarchical object type is the "tree" object. A tree object\r
is a list of mode/name/blob data, sorted by name. Alternatively, the\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 14-Feb-2007 07:23:36 UTC\r
+Last updated 18-Feb-2007 00:34:44 UTC\r
</div>\r
</div>\r
</body>\r
@@ -1 +1,2 @@\r
hello world!\r
+hello world, again\r
-$ git update-index file.txt\r
+$ git add file.txt\r
$ git diff</tt></pre>\r
</div></div>\r
<p>The last diff is empty, but no new commits have been made, and the\r
hello world!\r
hello world, again</tt></pre>\r
</div></div>\r
-<p>So what our "git update-index" did was store a new blob and then put\r
+<p>So what our "git add" did was store a new blob and then put\r
a reference to it in the index file. If we modify the file again,\r
we'll see that the new modifications are reflected in the "git-diff"\r
output:</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Feb-2007 08:07:24 UTC\r
+Last updated 18-Feb-2007 00:34:47 UTC\r
</div>\r
</div>\r
</body>\r
@@ -1 +1,2 @@
hello world!
+hello world, again
-$ git update-index file.txt
+$ git add file.txt
$ git diff
------------------------------------------------
hello world, again
------------------------------------------------
-So what our "git update-index" did was store a new blob and then put
+So what our "git add" did was store a new blob and then put
a reference to it in the index file. If we modify the file again,
we'll see that the new modifications are reflected in the "git-diff"
output: