--- /dev/null
+GIT v1.5.1.4 Release Notes
+==========================
+
+Fixes since v1.5.1.3
+--------------------
+
+* Bugfixes
+
+ - "git-http-fetch" did not work around a bug in libcurl
+ earlier than 7.16 (curl_multi_remove_handle() was broken).
+
+ - "git cvsserver" handles a file that was once removed and
+ then added again correctly.
+
+ - import-tars script (in contrib/) handles GNU tar archives
+ that contain pathnames longer than 100 bytes (long-link
+ extension) correctly.
+
+ - xdelta test program did not build correctly.
+
+ - gitweb sometimes tried incorrectly to apply function to
+ decode utf8 twice, resulting in corrupt output.
+
+ - "git blame -C" mishandled text at the end of a group of
+ lines.
+
+ - "git log/rev-list --boundary" did not produce output
+ correctly without --left-right option.
+
+ - Many documentation updates.
arbitrary filter to contents on check-in/check-out codepath
but this feature is an extremely sharp-edged razor and needs
to be handled with caution (do not use it unless you
- understand the earlier mailing list discussion on keyward
+ understand the earlier mailing list discussion on keyword
expansion).
* The packfile format now optionally suports 64-bit index.
needs more than 32-bit to express offsets of objects in the
pack
+* Comes with an updated git-gui 0.7.0
+
* New commands and options.
- "git bisect start" can optionally take a single bad commit and
- "git blame" uses .mailmap to canonicalize the author name
just like "git shortlog" does.
+ - "git pack-objects" pays attention to pack.depth
+ configuration variable.
+
+ - "git cherry-pick" and "git revert" does not use .msg file in
+ the working tree to prepare commit message; instead it uses
+ $GIT_DIR/MERGE_MSG as other commands.
+
* Builds
- git-p4import has never been installed; now there is an
renamed it. We do not do that when there is no rename, so
match that behaviour.
+ - The default pack depth has been increased to 50, as the
+ recent addition of delta_base_cache makes deeper delta chains
+ much less expensive to access.
+
+
Fixes since v1.5.1
------------------
- git-fetch had trouble with a remote with insanely large number
of refs.
+ - "git clean -d -X" now does not remove non-excluded directories.
+
* Documentation updates
* Performance Tweaks
--
exec >/var/tmp/1
-O=v1.5.2-rc1-32-g125a5f1
+O=v1.5.2-rc2-45-g618e613
echo O=`git describe refs/heads/master`
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint
The size of the window used by gitlink:git-pack-objects[1] when no
window size is given on the command line. Defaults to 10.
+pack.depth::
+ The maximum delta depth used by gitlink:git-pack-objects[1] when no
+ maximum depth is given on the command line. Defaults to 50.
+
pull.octopus::
The default merge strategy to use when pulling multiple branches
at once.
</p>\r
</dd>\r
<dt>\r
+pack.depth\r
+</dt>\r
+<dd>\r
+<p>\r
+ The maximum delta depth used by <a href="git-pack-objects.html">git-pack-objects(1)</a> when no\r
+ maximum depth is given on the command line. Defaults to 50.\r
+</p>\r
+</dd>\r
+<dt>\r
pull.octopus\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 04-May-2007 07:07:21 UTC\r
+Last updated 09-May-2007 07:15:31 UTC\r
</div>\r
</div>\r
</body>\r
it too deep affects the performance on the unpacker\r
side, because delta data needs to be applied that many\r
times to get to the necessary object.\r
- The default value for both --window and --depth is 10.\r
+ The default value for --window is 10 and --depth is 50.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 22-Apr-2007 05:47:51 UTC\r
+Last updated 09-May-2007 07:15:31 UTC\r
</div>\r
</div>\r
</body>\r
it too deep affects the performance on the unpacker
side, because delta data needs to be applied that many
times to get to the necessary object.
- The default value for both --window and --depth is 10.
+ The default value for --window is 10 and --depth is 50.
--incremental::
This flag causes an object already in a pack ignored
space. <tt>--depth</tt> limits the maximum delta depth; making it too deep\r
affects the performance on the unpacker side, because delta data needs\r
to be applied that many times to get to the necessary object.\r
- The default value for both --window and --depth is 10.\r
+ The default value for --window is 10 and --depth is 50.\r
</p>\r
</dd>\r
</dl>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 04-Apr-2007 18:34:08 UTC\r
+Last updated 09-May-2007 07:15:31 UTC\r
</div>\r
</div>\r
</body>\r
space. `--depth` limits the maximum delta depth; making it too deep
affects the performance on the unpacker side, because delta data needs
to be applied that many times to get to the necessary object.
- The default value for both --window and --depth is 10.
+ The default value for --window is 10 and --depth is 50.
Configuration
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 08-May-2007 00:32:27 UTC\r
+Last updated 09-May-2007 07:15:32 UTC\r
</div>\r
</div>\r
</body>\r
* link:RelNotes-1.5.1.txt[release notes for 1.5.1]
-* link:v1.5.1.2/git.html[documentation for release 1.5.1.2]
+* link:v1.5.1.4/git.html[documentation for release 1.5.1.4]
+
+* link:RelNotes-1.5.1.4.txt[release notes for 1.5.1.4]
+
+* link:RelNotes-1.5.1.3.txt[release notes for 1.5.1.3]
* link:RelNotes-1.5.1.2.txt[release notes for 1.5.1.2]
| |
| they push V
their public repo <------------------- their repo</pre><p>Now, assume your personal repository is in the directory ~/proj. We
-first create a new clone of the repository:</p><div class="literallayout"><p>$ git clone --bare proj.git</p></div><p>The resulting directory proj.git will contains a "bare" git
-repository—it is just the contents of the ".git" directory, without
-a
checked-out copy of a working directory.</p><p>Next, copy proj.git to the server where you plan to host the
+first create a new clone of the repository:</p><div class="literallayout"><p>$ git clone --bare ~/proj proj.git</p></div><p>The resulting directory proj.git contains a "bare" git repository—it is
+just the contents of the ".git" directory, without a checked-out copy of
+a working directory.</p><p>Next, copy proj.git to the server where you plan to host the
public repository. You can use scp, rsync, or whatever is most
convenient.</p><p>If somebody else maintains the public server, they may already have
set up a git service for you, and you may skip to the section
branch.master.merge=refs/heads/master</p></div><p>If there are other repositories that you also use frequently, you can
create similar configuration options to save typing; for example,
after</p><div class="literallayout"><p>$ git config remote.example.url git://example.com/proj.git</p></div><p>then the following two commands will do the same thing:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git master:refs/remotes/example/master<br>
-$ git fetch example master:refs/remotes/example/master</p></div><p>Even better, if you add one more option:</p><div class="literallayout"><p>$ git config remote.example.fetch master:refs/remotes/example/master</p></div><p>then the following commands will all do the same thing:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git master:ref/remotes/example/master<br>
-$ git fetch example master:ref/remotes/example/master<br>
-$ git fetch example example/master<br>
+$ git fetch example master:refs/remotes/example/master</p></div><p>Even better, if you add one more option:</p><div class="literallayout"><p>$ git config remote.example.fetch master:refs/remotes/example/master</p></div><p>then the following commands will all do the same thing:</p><div class="literallayout"><p>$ git fetch git://example.com/proj.git master:refs/remotes/example/master<br>
+$ git fetch example master:refs/remotes/example/master<br>
$ git fetch example</p></div><p>You can also add a "+" to force the update each time:</p><div class="literallayout"><p>$ git config remote.example.fetch +master:ref/remotes/example/master</p></div><p>Don't do this unless you're sure you won't mind "git fetch" possibly
throwing away commits on mybranch.</p><p>Also note that all of the above configuration can be performed by
directly editing the file .git/config instead of using
first create a new clone of the repository:
-------------------------------------------------
-$ git clone --bare proj.git
+$ git clone --bare ~/proj proj.git
-------------------------------------------------
-The resulting directory proj.git will contains a "bare" git
-repository--it is just the contents of the ".git" directory, without
-a checked-out copy of a working directory.
+The resulting directory proj.git contains a "bare" git repository--it is
+just the contents of the ".git" directory, without a checked-out copy of
+a working directory.
Next, copy proj.git to the server where you plan to host the
public repository. You can use scp, rsync, or whatever is most
then the following commands will all do the same thing:
-------------------------------------------------
-$ git fetch git://example.com/proj.git master:ref/remotes/example/master
-$ git fetch example master:ref/remotes/example/master
-$ git fetch example example/master
+$ git fetch git://example.com/proj.git master:refs/remotes/example/master
+$ git fetch example master:refs/remotes/example/master
$ git fetch example
-------------------------------------------------
projects / git.git / commitdiff