[ANNOUNCE] Git 1.7.9.3

The latest maintenance release Git 1.7.9.3 is now available at the usual places. Time to upgrade.

The release tarballs are found at:

    http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

6216153da1139c25cb96cfb4441eff327013ec4f git-1.7.9.3.tar.gz 2d488c3975da1c2ea90965b82233a986c498a8c2 git-htmldocs-1.7.9.3.tar.gz 223daa871a64facc60bdf643c50c78eac21c88f4 git-manpages-1.7.9.3.tar.gz

Also the following public repositories all have a copy of the v1.7.9.3 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 v1.7.9.3 Release Notes ==========================

Fixes since v1.7.9.2 --------------------

 * "git p4" (in contrib/) submit the changes to a wrong place when the
   "--use-client-spec" option is set.

 * The config.mak.autogen generated by optional autoconf support tried
   to link the binary with -lintl even when libintl.h is missing from
   the system.

 * When the filter driver exits before reading the content before the
   main git process writes the contents to be filtered to the pipe to
   it, the latter could be killed with SIGPIPE instead of ignoring
   such an event as an error.

 * "git add --refresh <pathspec>" used to warn about unmerged paths
   outside the given pathspec.

 * The bulk check-in codepath in "git add" streamed contents that
   needs smudge/clean filters without running them, instead of punting
   and delegating to the codepath to run filters after slurping
   everything to core.

 * "git branch --with $that" assumed incorrectly that the user will never
   ask the question with nonsense value in $that.

 * "git bundle create" produced a corrupt bundle file upon seeing
   commits with excessively long subject line.

 * When a remote helper exits before reading the blank line from the
   main git process to signal the end of commands, the latter could be
   killed with SIGPIPE. Instead we should ignore such event as a
   non-error.

 * The commit log template given with "git merge --edit" did not have
   a short instructive text like what "git commit" gives.

 * "git rev-list --verify-objects -q" omitted the extra verification
   it needs to do over "git rev-list --objects -q" by mistake.

 * "gitweb" used to drop warnings in the log file when "heads" view is
   accessed in a repository whose HEAD does not point at a valid
   branch.

 * An invalid regular expression pattern given by an end user made
   "gitweb" to return garbled response.

Also contains minor fixes and documentation updates.

----------------------------------------------------------------

Changes since v1.7.9.2 are as follows:

Andrew Wong (1):
      rebase -m: only call "notes copy" when rewritten exists and is non-empty

Carlos Martín Nieto (2):
      branch: don't assume the merge filter ref exists
      Documentation: use {asterisk} in rev-list-options.txt when needed

Clemens Buchacher (1):
      http.proxy: also mention https_proxy and all_proxy

Dmitry V. Levin (1):
      Makefile: add thread-utils.h to LIB_H

Jakub Narebski (2):
      gitweb: Fix "heads" view when there is no current branch
      gitweb: Handle invalid regexp in regexp search

Jeff King (4):
      disconnect from remote helpers more gently
      teach convert_to_git a "dry run" mode
      teach dry-run convert_to_git not to require a src buffer
      do not stream large files to pack when filters are in use

Jehan Bing (1):
      Ignore SIGPIPE when running a filter driver

Jim Meyering (1):
      am: don't infloop for an empty input file

John Szakmeister (1):
      configure: don't use -lintl when there is no gettext support

Jonathan Nieder (1):
      mergetools/meld: Use --help output to detect --output support

Junio C Hamano (9):
      refresh_index: do not show unmerged path that is outside pathspec
      Documentation/merge-options.txt: group "ff" related options together
      Document merge.branchdesc configuration variable
      Git 1.7.8.5
      Document accumulated fixes since 1.7.9.2
      Update draft release notes to 1.7.9.3
      Documentation: do not assume that n > 1 in <rev>~$n
      Update draft release notes to 1.7.9.3 for the last time
      Git 1.7.9.3

Libor Pechacek (1):
      Documentation fixes in git-config

Matthieu Moy (1):
      README: point to Documentation/SubmittingPatches

Michael Haggerty (2):
      post-receive-email: remove unused variable
      post-receive-email: match up $LOGBEGIN..$LOGEND pairs correctly

Michael J Gruber (1):
      t0300: work around bug in dash 0.5.6

Michał Kiedrowicz (1):
      grep -P: Fix matching ^ and $

Nguyễn Thái Ngọc Duy (2):
      rev-list: remove BISECT_SHOW_TRIED flag
      rev-list: fix --verify-objects --quiet becoming --objects

Pete Wyckoff (4):
      git-p4: set useClientSpec variable on initial clone
      git-p4: fix submit regression with clientSpec and subdir clone
      git-p4: remove bash-ism in t9809
      git-p4: remove bash-ism in t9800

Philip Jägenstedt (1):
      remote: fix set-branches usage and documentation

Stefano Lattarini (1):
      tests: fix spurious error when run directly with Solaris /usr/xpg4/bin/sh

Thomas Rast (6):
      merge: add instructions to the commit message when editing
      bundle: put strbuf_readline_fd in strbuf.c with adjustments
      bundle: use a strbuf to scan the log for boundary commits
      strbuf: improve strbuf_get*line documentation
      t5704: match tests to modern style
      fast-import: zero all of 'struct tag' to silence valgrind

Tim Henigan (2):
      CodingGuidelines: Add a note about spaces after redirection
      CodingGuidelines: do not use 'which' in shell scripts

Tom Grennan (1):
      t5512 (ls-remote): modernize style

On Mar 5, 2012, at 18:24 , Junio C Hamano wrote:

This fix (bc2fed496baa54ae99dede7da23dec938adbf0eb) modified test t5704 which now fails on my Mac (10.7.3)

*** t5704-bundle.sh *** ok 1 - setup ok 2 - tags can be excluded by rev-list options ok 3 - die if bundle file cannot be created not ok 4 - bundle --stdin # TODO known breakage not ok 5 - bundle --stdin <rev-list options> # TODO known breakage ok 6 - empty bundle file is rejected not ok - 7 ridiculously long subject in boundary # # : >file4 && # test_tick && # git add file4 && # printf "%01200d # " 0 | git commit -F - && # test_commit fifth && # git bundle create long-subject-bundle.bdl HEAD^..HEAD && # git bundle list-heads long-subject-bundle.bdl >heads && # test -s heads && # git fetch long-subject-bundle.bdl && # sed -n "/^-/{p;q}" long-subject-bundle.bdl >boundary && # grep "^-$_x40 " boundary # # still have 2 known breakage(s) # failed 1 among remaining 5 test(s) 1..7 make[3]: *** [t5704-bundle.sh] Error 1

BJ Hargrave <bj@bjhargrave.com> writes:

I can reproduce this. The failure (to be seen from -v, which would have been really nice to have in the original mail):

  sed: 1: "/^-/{p;q}": extra characters at the end of q command

This can be fixed with the change below, which then gets us into the next one

  grep: Regular expression too big

Sheesh, Apple, are you kidding me?! So we also need to change the grep expression.

----- 8< -----
Subject: [PATCH] t5704: fix nonportable sed/grep usages

OS X's sed and grep would complain with (respectively)

  sed: 1: "/^-/{p;q}": extra characters at the end of q command
  grep: Regular expression too big

For sed, use an explicit ; to terminate the q command.

For grep, spell the "40 hex digits" explicitly in the regex, instead
of being lazy with the shell pattern $_x40.
---
 t/t5704-bundle.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Thomas Rast <trast@inf.ethz.ch> writes:

Alright. we see trailing ;} in t4300.

Ok, that is what we already use in t5510 so it should be safe.

Thanks.

Thomas Rast <trast@inf.ethz.ch> writes:

Actually the shell pattern $_x40 was invented so that it can be used in both shell, grep and sed; there is nothing *lazy* about it.

I share the "are you kidding me?!" with you. I cannot fathom which part of that regular expression is too big for them to swallow.

In any case, thanks for a quick fix; can I consider it as signed-off?

Junio C Hamano <gitster@pobox.com> writes:

Oh, yes! Sorry about that. I pulled it from the OS X machine which did not have S-O-B appropriately configured.