[ANNOUNCE] Git v1.9.0
The latest feature release Git v1.9.0 is now available 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: e60667fc16e5a5f1cde46616b0458cc802707743 git-1.9.0.tar.gz 65eb3f411f4699695c7081a7c716cabb9ce23d75 git-htmldocs-1.9.0.tar.gz cff590c92b4d1c8a143c078473140b653cc5d56a git-manpages-1.9.0.tar.gz The following public repositories all have a copy of the v1.9.0 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 Also, http://www.kernel.org/pub/software/scm/git/ has copies of the release tarballs. Git v1.9.0 Release Notes Backward compatibility notes git submodule foreach $cmd $args used to treat $cmd $args the same way ssh did, concatenating them into a single string and letting the shell unquote. Careless users who forget to sufficiently quote $args get their argument split at $IFS whitespaces by the shell, and got unexpected results due to this. Starting from this release, the command line is passed directly to the shell, if it has an argument. Read-only support for experimental loose-object format, in which users could optionally choose to write their loose objects for a short while between v1.4.3 and v1.5.3 era, has been dropped. The meanings of the --tags option to git fetch has changed; the command fetches tags _in addition to_ what is fetched by the same command line without the option. The way git push $there $what interprets the $what part given on the command line, when it does not have a colon that explicitly tells us what ref at the $there repository is to be updated, has been enhanced. A handful of ancient commands that have long been deprecated are finally gone (repo-config, tar-tree, lost-found, and peek-remote). Backward compatibility notes (for Git 2.0.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, 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. 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 path will behave as git add -A path, 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 path 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.5 Foreign interfaces, subsystems and ports. * The HTTP transport, when talking GSS-Negotiate, uses 100 Continue response to avoid having to rewind and resend a large payload, which may not be always doable. * Various bugfixes to remote-bzr and remote-hg (in contrib/). * The build procedure is aware of MirBSD now. * Various git p4, git svn and gitk updates. UI, Workflows Features * Fetching from a shallowly-cloned repository used to be forbidden, primarily because the codepaths involved were
[ANNOUNCE] Git v1.9.0-rc3
A release candidate Git v1.9.0-rc3 is now available for testing at the usual places. Hopefully this will be the last one before the final, scheduled to happen sometime late next week. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: ed28a6dd2610f9f6052ce52f2eb6ab1db070a637 git-1.9.0.rc3.tar.gz 7512d3f0e2572face34416c2b9fda2385d490c82 git-htmldocs-1.9.0.rc3.tar.gz aac8cb1379f2d5e416db31a40ffb86deec902acc git-manpages-1.9.0.rc3.tar.gz The following public repositories all have a copy of the v1.9.0-rc3 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.9 Release Notes (draft) == Backward compatibility notes git submodule foreach $cmd $args used to treat $cmd $args the same way ssh did, concatenating them into a single string and letting the shell unquote. Careless users who forget to sufficiently quote $args gets their argument split at $IFS whitespaces by the shell, and got unexpected results due to this. Starting from this release, the command line is passed directly to the shell, if it has an argument. Read-only support for experimental loose-object format, in which users could optionally choose to write in their loose objects for a short while between v1.4.3 to v1.5.3 era, has been dropped. The meanings of --tags option to git fetch has changed; the command fetches tags _in addition to_ what are fetched by the same command line without the option. The way git push $there $what interprets $what part given on the command line, when it does not have a colon that explicitly tells us what ref at the $there repository is to be updated, has been enhanced. A handful of ancient commands that have long been deprecated are finally gone (repo-config, tar-tree, lost-found, and peek-remote). 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, 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. 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 path will behave as git add -A path, 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 path 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.5 Foreign interfaces, subsystems and ports. * The HTTP transport, when talking GSS-Negotiate, uses 100 Continue response to avoid having to rewind and resend a large payload, which may not be always doable. * Various bugfixes to remote-bzr and remote-hg (in contrib/). * The build procedure is aware of MirBSD now. * Various git p4, git svn and gitk updates. UI, Workflows Features * Fetching from a shallowly-cloned repository used to be forbidden, primarily
