An early preview release Git v2.0.0-rc0 is now available for
testing at the usual places.
A major version bump between v1.x.x series and the upcoming v2.0.0
means there are a handful of backward incompatible UI improvements,
but for most people, all the tricky preparation for the transition
would have been already done for you and the upcoming release just
flips the default. Unless you were living in a cave and have stayed
with an ancient version of Git (e.g. one before 1.8.2 that was
released more than a year ago) for all these times, that is---those
of you may want to double check the backward compatibility notes
section at the beginning of the draft release notes.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-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 v2.0 Release Notes (draft)
==
Backward compatibility notes
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 is now the "simple" semantics,
which 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.
You can use the configuration variable "push.default" to change
this. If you are an old-timer who wants to keep using the
"matching" semantics, you can set the variable to "matching", for
example. Read the documentation for other possibilities.
When "git add -u" and "git add -A" are run inside a subdirectory
without specifying which paths to add on the command line, they
operate on the entire tree for consistency with "git commit -a" and
other commands (these commands used to operate only on the current
subdirectory). Say "git add -u ." or "git add -A ." if you want to
limit the operation to the current directory.
"git add " is the same as "git add -A " now, so that
"git add dir/" will notice paths you removed from the directory and
record the removal. In older versions of Git, "git add " used
to ignore removals. You can say "git add --ignore-removal " to
add only added or modified paths in , if you really want to.
The "-q" option to "git diff-files", which does *NOT* mean "quiet",
has been removed (it told Git to ignore deletion, which you can do
with "git diff-files --diff-filter=d").
"git request-pull" lost a few "heuristics" that often led to mistakes.
Updates since v1.9 series
-
UI, Workflows & Features
* The "multi-mail" post-receive hook (in contrib/) has been updated
to a more recent version from the upstream.
* "git gc --aggressive" learned "--depth" option and
"gc.aggressiveDepth" configuration variable to allow use of a less
insane depth than the built-in default value of 250.
* "git log" learned the "--show-linear-break" option to show where a
single strand-of-pearls is broken in its output.
* The "rev-parse --parseopt" mechanism used by scripted Porcelains to
parse command line options and to give help text learned to take
the argv-help (the placeholder string for an option parameter,
e.g. "key-id" in "--gpg-sign=").
* The pattern to find where the function begins in C/C++ used in
"diff" and "grep -p" have been updated to help C++ source better.
* "git rebase" learned to interpret a lone "-" as "@{-1}", the
branch that we were previously on.
* "git commit --cleanup=" learned a new mode, scissors.
* "git tag --list" output can be sorted using "version sort" with
"--sort=version:refname".
* Discard the accumulated "heuristics" to guess from which branch the
result wants to be pulled from and make sure what the end user
specified is not second-guessed by "git request-pull", to avoid
mistakes. When you pushed out your 'master' branch to your public
repository as 'for-linus', use the new "master:for-linus" syntax to
denote the branch to be pulled.
* "git grep" learned to behave in a way similar to native grep when
"-h" (no header) and "-c" (count) options are given.
* transport-helper, fast-import and fast-export have been updated to
allow the ref mapping and ref deletion in a way similar to the
natively supported transports.
* The "simple" mode is the default for "git push"
