openSUSE Recommended Update: git: Update to bugfix-release 188.8.131.52 from 1.8.4
Announcement ID: openSUSE-RU-2014:0147-1
An update that has one recommended fix can now be installed.
This update fixes the following issues with git:
- bnc#859057: update to version 184.108.40.206, for fixing
* Recent update to remote-hg that attempted to make it
work better with non ASCII pathnames fed Unicode strings to
the underlying Hg API, which was wrong.
* "git submodule init" copied "submodule.$name.update"
settings from .gitmodules to .git/config without making
sure if the suggested value was sensible.
* The fix in v220.127.116.11 to the pack transfer protocol to
propagate the target of symbolic refs broke "git clone/git
fetch" from a repository with too many symbolic refs. As a
hotfix/workaround, we transfer only the information on HEAD.
* The interaction between use of Perl in our test suite
and NO_PERL has been clarified a bit.
* A fast-import stream expresses a pathname with funny
characters by quoting them in C style; remote-hg remote
helper (in contrib/) forgot to unquote such a path.
* One long-standing flaw in the pack transfer protocol
used by "git clone" was that there was no way to tell the
other end which branch "HEAD" points at, and the receiving
end needed to guess. A new capability has been defined in
the pack protocol to convey this information so that
cloning from a repository with more than one branches
pointing at the same commit where the HEAD is at now
reliably sets the initial branch in the resulting
* We did not handle cases where http transport gets
redirected during the authorization request (e.g. from
http:// to https://).
* "git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag
itself in the output, but "git rev-list --objects
v1.0^..v1.0" did not.
* The fall-back parsing of commit objects with broken
author or committer lines were less robust than ideal in
picking up the timestamps.
* Bash prompting code to deal with an SVN remote as an
upstream were coded in a way not supported by older Bash
* "git checkout topic", when there is not yet a local
"topic" branch but there is a unique remote-tracking branch
for a remote "topic" branch, pretended as if "git checkout
-t -b topic remote/$r/topic" (for that unique remote $r)
was run. This hack however was not implemented for "git
checkout topic --".
* Coloring around octopus merges in "log --graph"
output was screwy.
* We did not generate HTML version of documentation to
"git subtree" in contrib/.
* The synopsis section of "git unpack-objects"
documentation has been clarified a bit.
* An ancient How-To on serving Git repositories on an
HTTP server lacked a warning that it has been mostly
superseded with more modern way.
* "git clone" gave some progress messages to the
standard output, not to the standard error, and did not
allow suppressing them with the "--no-progress" option.
* "format-patch --from=<whom>" forgot to omit
unnecessary in-body from line, i.e. when <whom> is the same
as the real author.
* "git shortlog" used to choke and die when there is a
malformed commit (e.g. missing authors); it now simply
ignore such a commit and keeps going.
* "git merge-recursive" did not parse its
"--diff-algorithm=" command line option correctly.
* "git branch --track" had a minor regression in
v18.104.22.168 and later that made it impossible to base your
local work on anything but a local branch of the upstream
repository you are tracking from.
* "git ls-files -k" needs to crawl only the part of the
working tree that may overlap the paths in the index to
find killed files, but shared code with the logic to find
all the untracked files, which made it unnecessarily
* When there is no sufficient overlap between old and
new history during a "git fetch" into a shallow repository,
objects that the sending side knows the receiving end has
were unnecessarily sent.
* When running "fetch -q", a long silence while the
sender side computes the set of objects to send can be
mistaken by proxies as dropped connection. The server side
has been taught to send a small empty messages to keep the
* When the webserver responds with "405 Method Not
Allowed", "git http-backend" should tell the client what
methods are allowed with the "Allow" header.
* "git cvsserver" computed the permission mode bits
incorrectly for executable files.
* The implementation of "add -i" has a crippling code
to work around ActiveState Perl limitation but it by
mistake also triggered on Git for Windows where MSYS perl
* We made sure that we notice the user-supplied GIT_DIR
is actually a gitfile, but did not do the same when the
default ".git" is a gitfile.
* When an object is not found after checking the
packfiles and then loose object directory, read_sha1_file()
re-checks the packfiles to prevent racing with a concurrent
repacker; teach the same logic to has_sha1_file().
* "git commit --author=$name", when $name is not in the
canonical "A. U. Thor <au.thor(a)example.xz>" format, looks
for a matching name from existing history, but did not
consult mailmap to grab the preferred author name.
* The commit object names in the insn sheet that was
prepared at the beginning of "rebase -i" session can become
ambiguous as the rebasing progresses and the repository
gains more commits. Make sure the internal record is kept
with full 40-hex object names.
* "git rebase --preserve-merges" internally used the
merge machinery and as a side effect, left merge summary
message in the log, but when rebasing, there should not be
a need for merge summary.
* "git rebase -i" forgot that the comment character can
be configurable while reading its insn sheet.
* Some old versions of bash do not grok some constructs
like 'printf -v varname' which the prompt and completion
code started to use recently. The completion and prompt
scripts have been adjusted to work better with these old
versions of bash.
* In FreeBSD's and NetBSD's "sh", a return in a dot
script in a function returns from the function, not only in
the dot script, breaking "git rebase" on these platforms
(regression introduced in 1.8.4-rc1).
* "git rebase -i" and other scripted commands were
feeding a random, data dependant error message to 'echo'
and expecting it to come out literally.
* Setting the "submodule.<name>.path" variable to the
empty "true" caused the configuration parser to segfault.
* Output from "git log --full-diff -- <pathspec>"
looked strange because comparison was done with the
previous ancestor that touched the specified <pathspec>,
causing the patches for paths outside the pathspec to show
more than the single commit has changed.
* The auto-tag-following code in "git fetch" tries to
reuse the same transport twice when the serving end does
not cooperate and does not give tags that point to commits
that are asked for as part of the primary transfer.
Unfortunately, Git-aware transport helper interface is not
designed to be used more than once, hence this did not work
over smart-http transfer. Fixed.
* Send a large request to read(2)/write(2) as a smaller
but still reasonably large chunks, which would improve the
latency when the operation needs to be killed and
incidentally works around broken 64-bit systems that cannot
take a 2GB write or read in one go.
* A ".mailmap" file that ends with an incomplete line,
when read from a blob, was not handled properly.
* The recent "short-cut clone connectivity check" topic
broke a shallow repository when a fetch operation tries to
* When send-email comes up with an error message to die
with upon failure to start an SSL session, it tried to read
the error string from a wrong place.
* A call to xread() was used without a loop to cope
with short read in the codepath to stream large blobs to a
* On platforms with fgetc() and friends defined as
macros, the configuration parser did not compile.
* New versions of MediaWiki introduced a new API for
returning more than 500 results in response to a query,
which would cause the MediaWiki remote helper to go into an
* Subversion's serf access method (the only one
available in Subversion 1.8) for http and https URLs in
skelta mode tells its caller to open multiple files at a
time, which made "git svn fetch" complain that "Temp file
with moniker 'svn_delta' already in use" instead of
To install this openSUSE Recommended Update use YaST online_update.
Alternatively you can run the command listed for your product:
- openSUSE 13.1:
zypper in -t patch openSUSE-2014-88
To bring your system up-to-date, use "zypper patch".
- openSUSE 13.1 (i586 x86_64):