The latest maintenance release Git 126.96.36.199 is now available at
the usual places.
The release tarballs are found at:
and their SHA-1 checksums are:
e4b7f746ff4e356baaddcad0b2911376efde031b git-188.8.131.52.tar.gz 004a2bf989b935657e2e1e6000a748d83657649f git-htmldocs-184.108.40.206.tar.gz 6cc3f80185bdd1a608cf373b05313b2adc82b898 git-manpages-220.127.116.11.tar.gz
Also the following public repositories all have a copy of the v18.104.22.168
tag and the maint branch that the tag points at:
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 v22.214.171.124 Release Notes
Fixes since v126.96.36.199
The test scaffolding for git-daemon was flaky.
The test scaffolding for fast-import was flaky.
The filesystem boundary was not correctly reported when .git directory
discovery stopped at a mount point.
HTTP transport that requires authentication did not work correctly when
multiple connections are used simultaneously.
Minor memory leak during unpack_trees (hence “merge” and “checkout”
to check out another branch) has been plugged.
In the older days, the header “Conflicts:” in “cherry-pick” and “merge”
was separated by a blank line from the list of paths that follow for
readability, but when “merge” was rewritten in C, we lost it by
mistake. Remove the newline from “cherry-pick” to make them match
The command line parser choked “git cherry-pick $name” when $name can
be both revision name and a pathname, even though $name can never be a
path in the context of the command.
The “include.path” facility in the configuration mechanism added in
1.7.10 forgot to interpret “/path” and “user/path” as it should.
“git config –rename-section” to rename an existing section into a
bogus one did not check the new name.
The “diff –no-index” codepath used limited-length buffers, risking
pathnames getting truncated. Update it to use the strbuf API.
The report from “git fetch” said “new branch” even for a non branch
The http-backend (the server side of the smart http transfer) used
to overwrite GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL with the
value obtained from REMOTE_USER unconditionally, making it
impossible for the server side site-specific customization to use
different identity sources to affect the names logged. It now uses
REMOTE_USER only as a fallback value.
“log –graph” was not very friendly with “–stat” option and its
output had line breaks at wrong places.
Octopus merge strategy did not reduce heads that are recorded in the
final commit correctly.
“git push” over smart-http lost progress output a few releases ago;
this release resurrects it.
The error and advice messages given by “git push” when it fails due
to non-ff were not very helpful to new users; it has been broken
into three cases, and each is given a separate advice message.
The insn sheet given by “rebase -i” did not make it clear that the
insn lines can be re-ordered to affect the order of the commits in
the resulting history.
“git repack” used to write out unreachable objects as loose objects
when repacking, even if such loose objects will immediately pruned
due to its age.
A contrib script “rerere-train” did not work out of the box unless
user futzed with her $PATH.
“git rev-parse –show-prefix” used to emit nothing when run at the
top-level of the working tree, but now it gives a blank line.
The i18n of error message “git stash save” was not properly done.
“git submodule” used a sed script that some platforms mishandled.
When using a Perl script on a system where “perl” found on user’s
$PATH could be ancient or otherwise broken, we allow builders to
specify the path to a good copy of Perl with $PERL_PATH. The
gitweb test forgot to use that Perl when running its test.
Also contains minor fixes and documentation updates.
Junio C Hamano wrote on 11 May 2012