openSUSE Recommended Update: git: Update to bugfix-release 1.8.4.5 from 1.8.4 ______________________________________________________________________________ Announcement ID: openSUSE-RU-2014:0147-1 Rating: low References: #859057 Affected Products: openSUSE 13.1 ______________________________________________________________________________ An update that has one recommended fix can now be installed. Description: This update fixes the following issues with git: - bnc#859057: update to version 1.8.4.5, for fixing git-send-email issue + https://raw.github.com/git/git/master/Documentation/RelNotes /1.8.4.5.txt * 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. + https://raw.github.com/git/git/master/Documentation/RelNotes /1.8.4.4.txt * The fix in v1.8.4.3 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. + https://raw.github.com/git/git/master/Documentation/RelNotes /1.8.4.3.txt * 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 repository. * 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 versions (3.x). * "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. + https://raw.github.com/git/git/master/Documentation/RelNotes /1.8.4.2.txt * "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 v1.8.3.2 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 inefficient. * 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 connection alive. * 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 is used. * 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@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. + https://raw.github.com/git/git/master/Documentation/RelNotes /1.8.4.1.txt * 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 auto-follow tags. * 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 pack. * 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 infinite loop. * 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 fetching. Patch Instructions: 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". Package List: - openSUSE 13.1 (i586 x86_64): git-1.8.4.5-3.4.1 git-arch-1.8.4.5-3.4.1 git-core-1.8.4.5-3.4.1 git-core-debuginfo-1.8.4.5-3.4.1 git-cvs-1.8.4.5-3.4.1 git-daemon-1.8.4.5-3.4.1 git-daemon-debuginfo-1.8.4.5-3.4.1 git-debugsource-1.8.4.5-3.4.1 git-email-1.8.4.5-3.4.1 git-gui-1.8.4.5-3.4.1 git-remote-helpers-1.8.4.5-3.4.1 git-svn-1.8.4.5-3.4.1 git-svn-debuginfo-1.8.4.5-3.4.1 git-web-1.8.4.5-3.4.1 gitk-1.8.4.5-3.4.1 References: https://bugzilla.novell.com/859057