An early preview Git v1.8.5-rc0 is now available for testing at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
591a2397df1bd14ea010df6980026d64df7f9653 git-1.8.5.rc0.tar.gz
be710eb67af014248ab09972e1e409a1fd847911 git-htmldocs-1.8.5.rc0.tar.gz
d42fdb41a9f480feda3ee7fa43b39dae105ea5b6 git-manpages-1.8.5.rc0.tar.gz
The following public repositories all have a copy of the v1.8.5-rc0
tag and the master branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.5 Release Notes (draft)
Backward compatibility notes (for Git 2.0)
--
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). In Git 2.0, the default will change to the "simple"
semantics that pushes:
- only the current branch to the branch with the same name, and only
when the current branch is set to integrate with that remote
branch, if you are pushing to the same remote as you fetch from; or
- only the current branch to the branch with the same name, if you
are pushing to a remote that is not where you usually fetch from.
Use the user preference configuration variable "push.default" to
change this. If you are an old-timer who is used to the "matching"
semantics, you can set the variable to "matching" to keep the
traditional behaviour. If you want to live in the future early, you
can set it to "simple" today without waiting for Git 2.0.
When "git add -u" (and "git add -A") is run inside a subdirectory and
does not specify which paths to add on the command line, it
will operate on the entire tree in Git 2.0 for consistency
with "git commit -a" and other commands. There will be no
mechanism to make plain "git add -u" behave like "git add -u .".
Current users of "git add -u" (without a pathspec) should start
training their fingers to explicitly say "git add -u ."
before Git 2.0 comes. A warning is issued when these commands are
run without a pathspec and when you have local changes outside the
current directory, because the behaviour in Git 2.0 will be different
from today's version in such a situation.
In Git 2.0, "git add " will behave as "git add -A ", so
that "git add dir/" will notice paths you removed from the directory
and record the removal. Versions before Git 2.0, including this
release, will keep ignoring removals, but the users who rely on this
behaviour are encouraged to start using "git add --ignore-removal "
now before 2.0 is released.
The default prefix for "git svn" will change in Git 2.0. For a long
time, "git svn" created its remote-tracking branches directly under
refs/remotes, but it will place them under refs/remotes/origin/ unless
it is told otherwise with its --prefix option.
Updates since v1.8.4
Foreign interfaces, subsystems and ports.
* "git-svn" used with SVN 1.8.0 when talking over https:// connection
dumped core due to a bug in the serf library that SVN uses. Work
it around on our side, even though the SVN side is being fixed.
* On MacOS X, we detected if the filesystem needs the "pre-composed
unicode strings" workaround, but did not automatically enable it.
Now we do.
* remote-hg remote helper misbehaved when interacting with a local Hg
repository relative to the home directory, e.g. "clone hg::~/there".
* imap-send ported to OS X uses Apple's security framework instead of
OpenSSL one.
* Subversion 1.8.0 that was recently released breaks older subversion
clients coming over http/https in various ways.
* "git fast-import" treats an empty path given to "ls" as the root of
the tree.
UI, Workflows & Features
* "git grep" and "git show" pays attention to "--textconv" option
when these commands are told to operate on blob objects (e.g. "git
grep -e pattern HEAD:Makefile").
* "git replace" helper no longer allows an object to be replaced with
another object of a different type to avoid confusion (you can
still manually craft such replacement using "git update-ref", as an
escape hatch).
* "git status" no longer prints dirty status information for
submodules for which submodule.$name.ignore is set to "all".
* "git rebase -i" honours core.abbrev when preparing the insn sheet
for editing.
* "git status" during a cherry-pick shows what original commit is
being picked.
* Instead of typing four capital letters "HEAD", you can say "@" now,
e.g. "git log @".
* "git check-ignore" follows the same rule as "git ad
