{"thread":{"id":"38061","subject":"[ANNOUNCE] Git v2.2.0","startedAt":"2014-11-26T23:09:22Z","lastAt":"2014-12-03T16:45:33Z","messageCount":15,"participants":["Junio C Hamano","Steven Noonan","Jeff King","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"252618","messageId":"xmqqr3wpo8yl.fsf@gitster.dls.corp.google.com","threadId":"38061","inReplyTo":null,"subject":"[ANNOUNCE] Git v2.2.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-26T23:09:22Z","receivedAt":"2014-11-26T23:09:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest feature release Git v2.2 is now available at the usual\nplaces.  Big thanks go to 77 contributors, among which 20 are new\npeople, who made 550+ changes in total since Git v2.1 was released.\n\nThe tarballs are found at:\n\n    https://www.kernel.org/pub/software/scm/git/\n\nThe following public repositories all have a copy of the 'v2.2.0'\ntag and the 'master' branch that the tag points at:\n\n  url = https://kernel.googlesource.com/pub/scm/git/git\n  url = git://repo.or.cz/alt-git.git\n  url = https://code.google.com/p/git-core/\n  url = git://git.sourceforge.jp/gitroot/git-core/git.git\n  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core\n  url = https://github.com/gitster/git\n\nGit v2.2 Release Notes\n======================\n\nUpdates since v2.1\n------------------\n\nPorts\n\n * Building on older MacOS X systems automatically sets\n   the necessary NO_APPLE_COMMON_CRYPTO build-time option.\n\n * Building with NO_PTHREADS has been resurrected.\n\n * Compilation options have been updated a bit to better support the\n   z/OS port.\n\n\nUI, Workflows & Features\n\n * \"git archive\" learned to filter what gets archived with a pathspec.\n\n * \"git config --edit --global\" starts from a skeletal per-user\n   configuration file contents, instead of a total blank, when the\n   user does not already have any global config.  This immediately\n   reduces the need to later ask \"Have you forgotten to set\n   core.user?\", and we can add more to the template as we gain\n   more experience.\n\n * \"git stash list -p\" used to be almost always a no-op because each\n   stash entry is represented as a merge commit.  It learned to show\n   the difference between the base commit version and the working tree\n   version, which is in line with what \"git stash show\" gives.\n\n * Sometimes users want to report a bug they experience on their\n   repository, but they are not at liberty to share the contents of\n   the repository.  \"fast-export\" was taught an \"--anonymize\" option\n   to replace blob contents, names of people, paths and log\n   messages with bland and simple strings to help them.\n\n * \"git difftool\" learned an option to stop feeding paths to the\n   diff backend when it exits with a non-zero status.\n\n * \"git grep\" learned to paint (or not paint) partial matches on\n   context lines when showing \"grep -C<num>\" output in color.\n\n * \"log --date=iso\" uses a slight variant of the ISO 8601 format that is\n   more human readable.  A new \"--date=iso-strict\" option gives\n   datetime output that conforms more strictly.\n\n * The logic \"git prune\" uses is more resilient against various corner\n   cases.\n\n * A broken reimplementation of Git could write an invalid index that\n   records both stage #0 and higher-stage entries for the same path.\n   We now notice and reject such an index, as there is no sensible\n   fallback (we do not know if the broken tool wanted to resolve and\n   forgot to remove the higher-stage entries, or if it wanted to unresolve\n   and forgot to remove the stage #0 entry).\n\n * The temporary files \"git mergetool\" uses are renamed to avoid too\n   many dots in them (e.g. a temporary file for \"hello.c\" used to be\n   named e.g. \"hello.BASE.4321.c\" but now uses underscore instead,\n   e.g. \"hello_BASE_4321.c\", to allow us to have multiple variants).\n\n * The temporary files \"git mergetool\" uses can be placed in a newly\n   created temporary directory, instead of the current directory, by\n   setting the mergetool.writeToTemp configuration variable.\n\n * \"git mergetool\" understands \"--tool bc\" now, as version 4 of\n   BeyondCompare can be driven the same way as its version 3 and it\n   feels awkward to say \"--tool bc3\" to run version 4.\n\n * The \"pre-receive\" and \"post-receive\" hooks are no longer required\n   to consume their input fully (not following this requirement used\n   to result in intermittent errors in \"git push\").\n\n * The pretty-format specifier \"%d\", which expands to \" (tagname)\"\n   for a tagged commit, gained a cousin \"%D\" that just gives the\n   \"tagname\" without frills.\n\n * \"git push\" learned \"--signed\" push, that allows a push (i.e.\n   request to update the refs on the other side to point at a new\n   history, together with the transmission of necessary objects) to be\n   signed, so that it can be verified and audited, using the GPG\n   signature of the person who pushed, that the tips of branches at a\n   public repository really point the commits the pusher wanted to,\n   without having to \"trust\" the server.\n\n * \"git interpret-trailers\" is a new filter to programmatically edit\n   the tail end of the commit log messages, e.g. \"Signed-off-by:\".\n\n * \"git help everyday\" shows the \"Everyday Git in 20 commands or so\"\n   document, whose contents have been updated to match more modern\n   Git practice.\n\n * On the \"git svn\" front, work progresses to reduce memory consumption and\n   to improve handling of mergeinfo.\n\n\nPerformance, Internal Implementation, Development Support etc.\n\n * The API to manipulate the \"refs\" has been restructured to make it\n   more transactional, with the eventual goal to allow all-or-none\n   atomic updates and migrating the storage to something other than\n   the traditional filesystem based one (e.g. databases).\n\n * The lockfile API and its users have been cleaned up.\n\n * We no longer attempt to keep track of individual dependencies to\n   the header files in the build procedure, relying instead on automated\n   dependency generation support from modern compilers.\n\n * In tests, we have been using NOT_{MINGW,CYGWIN} test prerequisites\n   long before negated prerequisites e.g. !MINGW were invented.\n   The former has been converted to the latter to avoid confusion.\n\n * Optimized looking up a remote's configuration in a repository with very many\n   remotes defined.\n\n * There are cases where you lock and open to write a file, close it\n   to show the updated contents to an external processes, and then have\n   to update the file again while still holding the lock; now the\n   lockfile API has support for such an access pattern.\n\n * The API to allocate the structure to keep track of commit\n   decoration has been updated to make it less cumbersome to use.\n\n * An in-core caching layer to let us avoid reading the same\n   configuration files several times has been added.  A few commands\n   have been converted to use this subsystem.\n\n * Various code paths have been cleaned up and simplified by using\n   the \"strbuf\", \"starts_with()\", and \"skip_prefix()\" APIs more.\n\n * A few codepaths that died when large blobs that would not fit in\n   core are involved in their operation have been taught to punt\n   instead, by e.g. marking a too-large blob as not to be diffed.\n\n * A few more code paths in \"commit\" and \"checkout\" have been taught\n   to repopulate the cache-tree in the index, to help speed up later\n   \"write-tree\" (used in \"commit\") and \"diff-index --cached\" (used in\n   \"status\").\n\n * A common programming mistake to assign the same short option name\n   to two separate options is detected by the parse_options() API to help\n   developers.\n\n * The code path to write out the packed-refs file has been optimized,\n   which especially matters in a repository with a large number of\n   refs.\n\n * The check to see if a ref $F can be created by making sure no\n   existing ref has $F/ as its prefix has been optimized, which\n   especially matters in a repository with a large number of existing\n   refs.\n\n * \"git fsck\" was taught to check the contents of tag objects a bit more.\n\n * \"git hash-object\" was taught a \"--literally\" option to help\n   debugging.\n\n * When running a required clean filter, we do not have to mmap the\n   original before feeding the filter.  Instead, stream the file\n   contents directly to the filter and process its output.\n\n * The scripts in the test suite can be run with the \"-x\" option to show\n   a shell-trace of each command they run.\n\n * The \"run-command\" API learned to manage the argv and environment\n   arrays for child process, alleviating the need for the callers to\n   allocate and deallocate them.\n\n * Some people use AsciiDoctor, instead of AsciiDoc, to format our\n   documentation set; the documentation has been adjusted to be usable\n   by both, as AsciiDoctor is pickier than AsciiDoc about its input\n   mark-up.\n\n\nAlso contains various documentation updates and code clean-ups.\n\n\nFixes since v2.1\n----------------\n\nUnless otherwise noted, all the fixes since v2.1 in the maintenance\ntrack are contained in this release (see the maintenance releases'\nnotes for details).\n\n * \"git log --pretty/format=\" with an empty format string did not\n   mean the more obvious \"No output whatsoever\" but \"Use default\n   format\", which was counterintuitive.\n\n * \"git -c section.var command\" and \"git -c section.var= command\"\n   should pass the configuration value differently (the former should be a\n   boolean true, the latter should be an empty string).\n\n * Applying a patch not generated by Git in a subdirectory used to\n   check for whitespace breakage using the attributes of incorrect\n   paths. Also whitespace checks were performed even for paths\n   excluded via the \"git apply --exclude=<path>\" mechanism.\n\n * \"git bundle create\" with a date-range specification was meant to\n   exclude tags outside the range, but it didn't.\n\n * \"git add x\" where x used to be a directory and is now a\n   symbolic link to a directory misbehaved.\n\n * The prompt script checked the $GIT_DIR/ref/stash file to see if there\n   is a stash, which was a no-no.\n\n * Pack-protocol documentation had a minor typo.\n\n * \"git checkout -m\" did not switch to another branch while carrying\n   the local changes forward when a path was deleted from the index.\n\n * \"git daemon\" (with NO_IPV6 build configuration) used to incorrectly\n   use the hostname even when gethostbyname() reported that the given\n   hostname is not found.\n   (merge 107efbe rs/daemon-fixes later to maint).\n\n * With sufficiently long refnames, \"git fast-import\" could have\n   overflowed an on-stack buffer.\n\n * After \"pack-refs --prune\" packed refs at the top-level, it failed\n   to prune them.\n\n * Progress output from \"git gc --auto\" was visible in \"git fetch -q\".\n\n * We used to pass -1000 to poll(2), expecting it to also mean \"no\n   timeout\", which should be spelled as -1.\n\n * \"git rebase\" documentation was unclear that it is required to\n   specify on what <upstream> the rebase is to be done when telling it\n   to first check out <branch>.\n   (merge 95c6826 so/rebase-doc later to maint).\n\n * \"git push\" over HTTP transport had an artificial limit on the number of\n   refs that can be pushed, imposed by the command line length.\n   (merge 26be19b jk/send-pack-many-refspecs later to maint).\n\n * When receiving an invalid pack stream that records the same object\n   twice, multiple threads got confused due to a race.\n   (merge ab791dd jk/index-pack-threading-races later to maint).\n\n * An attempt to remove the entire tree in the \"git fast-import\" input\n   stream caused it to misbehave.\n   (merge 2668d69 mb/fast-import-delete-root later to maint).\n\n * Reachability check (used in \"git prune\" and friends) did not add a\n   detached HEAD as a starting point to traverse objects still in use.\n   (merge c40fdd0 mk/reachable-protect-detached-head later to maint).\n\n * \"git config --add section.var val\" when section.var already has an\n   empty-string value used to lose the empty-string value.\n   (merge c1063be ta/config-add-to-empty-or-true-fix later to maint).\n\n * \"git fsck\" failed to report that it found corrupt objects via its\n   exit status in some cases.\n   (merge 30d1038 jk/fsck-exit-code-fix later to maint).\n\n * Use of the \"--verbose\" option used to break \"git branch --merged\".\n   (merge 12994dd jk/maint-branch-verbose-merged later to maint).\n\n * Some MUAs mangle a line in a message that begins with \"From \" to\n   \">From \" when writing to a mailbox file, and feeding such an input\n   to \"git am\" used to lose such a line.\n   (merge 85de86a jk/mbox-from-line later to maint).\n\n * \"rev-parse --verify --quiet $name\" is meant to quietly exit with a\n   non-zero status when $name is not a valid object name, but still\n   gave error messages in some cases.\n\n * A handful of C source files have been updated to include\n   \"git-compat-util.h\" as the first thing, to conform better to our\n   coding guidelines.\n   (merge 1c4b660 da/include-compat-util-first-in-c later to maint).\n\n * The t7004 test, which tried to run Git with small stack space, has been\n   updated to use a bit larger stack to avoid false breakage on some\n   platforms.\n   (merge b9a1907 sk/tag-contains-wo-recursion later to maint).\n\n * A few documentation pages had example sections marked up not quite\n   correctly, which passed AsciiDoc but failed with AsciiDoctor.\n   (merge c30c43c bc/asciidoc-pretty-formats-fix later to maint).\n   (merge f8a48af bc/asciidoc later to maint).\n\n * \"gitweb\" used deprecated CGI::startfrom, which was removed from\n   CGI.pm as of 4.04; use CGI::start_from instead.\n   (merge 4750f4b rm/gitweb-start-form later to maint).\n\n * Newer versions of 'meld' break the auto-detection we use to see if\n   they are new enough to support the `--output` option.\n   (merge b12d045 da/mergetool-meld later to maint).\n\n * \"git pack-objects\" forgot to disable the codepath to generate the\n   object reachability bitmap when it needs to split the resulting\n   pack.\n   (merge 2113471 jk/pack-objects-no-bitmap-when-splitting later to maint).\n\n * The code to use cache-tree trusted the on-disk data too much and\n   fell into an infinite loop upon seeing an incorrectly recorded\n   index file.\n   (merge 729dbbd jk/cache-tree-protect-from-broken-libgit2 later to maint).\n\n * \"git fetch\" into a repository where branch B was deleted earlier,\n   back when it had reflog enabled, and then branch B/C is fetched\n   into it without reflog enabled, which is arguably an unlikely\n   corner case, unnecessarily failed.\n   (merge aae828b jk/fetch-reflog-df-conflict later to maint).\n\n * \"git log --first-parent -L...\" used to crash.\n   (merge a8787c5 tm/line-log-first-parent later to maint).\n"},{"id":"252649","messageId":"20141127213224.GA27443@dispater.uplinklabs.net","threadId":"38061","inReplyTo":"xmqqr3wpo8yl.fsf@gitster.dls.corp.google.com","subject":"Re: [ANNOUNCE] Git v2.2.0","fromName":"Steven Noonan","fromEmail":"steven@uplinklabs.net","sentAt":"2014-11-27T21:32:24Z","receivedAt":"2014-11-27T21:32:24Z","isPatch":false,"sender":{"key":"steven@uplinklabs.net","avatar":"https://gravatar.com/avatar/b0cd397a10638433f76e084531aa0af3bef85f8fdb59b1ebe2ddaf168cd100e9?d=mp&s=160"},"body":"On Wed, Nov 26, 2014 at 3:09 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> The latest feature release Git v2.2 is now available at the usual\n> places.  Big thanks go to 77 contributors, among which 20 are new\n> people, who made 550+ changes in total since Git v2.1 was released.\n>\n> The tarballs are found at:\n>\n>     https://www.kernel.org/pub/software/scm/git/\n>\n> The following public repositories all have a copy of the 'v2.2.0'\n> tag and the 'master' branch that the tag points at:\n>\n>   url = https://kernel.googlesource.com/pub/scm/git/git\n>   url = git://repo.or.cz/alt-git.git\n>   url = https://code.google.com/p/git-core/\n>   url = git://git.sourceforge.jp/gitroot/git-core/git.git\n>   url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core\n>   url = https://github.com/gitster/git\n>\n> Git v2.2 Release Notes\n> ======================\n>\n> Updates since v2.1\n> ------------------\n>\n> Ports\n>\n>  * Building on older MacOS X systems automatically sets\n>    the necessary NO_APPLE_COMMON_CRYPTO build-time option.\n>\n>  * Building with NO_PTHREADS has been resurrected.\n>\n>  * Compilation options have been updated a bit to better support the\n>    z/OS port.\n>\n>\n> UI, Workflows & Features\n>\n>  * \"git archive\" learned to filter what gets archived with a pathspec.\n>\n>  * \"git config --edit --global\" starts from a skeletal per-user\n>    configuration file contents, instead of a total blank, when the\n>    user does not already have any global config.  This immediately\n>    reduces the need to later ask \"Have you forgotten to set\n>    core.user?\", and we can add more to the template as we gain\n>    more experience.\n>\n>  * \"git stash list -p\" used to be almost always a no-op because each\n>    stash entry is represented as a merge commit.  It learned to show\n>    the difference between the base commit version and the working tree\n>    version, which is in line with what \"git stash show\" gives.\n>\n>  * Sometimes users want to report a bug they experience on their\n>    repository, but they are not at liberty to share the contents of\n>    the repository.  \"fast-export\" was taught an \"--anonymize\" option\n>    to replace blob contents, names of people, paths and log\n>    messages with bland and simple strings to help them.\n>\n>  * \"git difftool\" learned an option to stop feeding paths to the\n>    diff backend when it exits with a non-zero status.\n>\n>  * \"git grep\" learned to paint (or not paint) partial matches on\n>    context lines when showing \"grep -C<num>\" output in color.\n>\n>  * \"log --date=iso\" uses a slight variant of the ISO 8601 format that is\n>    more human readable.  A new \"--date=iso-strict\" option gives\n>    datetime output that conforms more strictly.\n>\n>  * The logic \"git prune\" uses is more resilient against various corner\n>    cases.\n>\n>  * A broken reimplementation of Git could write an invalid index that\n>    records both stage #0 and higher-stage entries for the same path.\n>    We now notice and reject such an index, as there is no sensible\n>    fallback (we do not know if the broken tool wanted to resolve and\n>    forgot to remove the higher-stage entries, or if it wanted to unresolve\n>    and forgot to remove the stage #0 entry).\n>\n>  * The temporary files \"git mergetool\" uses are renamed to avoid too\n>    many dots in them (e.g. a temporary file for \"hello.c\" used to be\n>    named e.g. \"hello.BASE.4321.c\" but now uses underscore instead,\n>    e.g. \"hello_BASE_4321.c\", to allow us to have multiple variants).\n>\n>  * The temporary files \"git mergetool\" uses can be placed in a newly\n>    created temporary directory, instead of the current directory, by\n>    setting the mergetool.writeToTemp configuration variable.\n>\n>  * \"git mergetool\" understands \"--tool bc\" now, as version 4 of\n>    BeyondCompare can be driven the same way as its version 3 and it\n>    feels awkward to say \"--tool bc3\" to run version 4.\n>\n>  * The \"pre-receive\" and \"post-receive\" hooks are no longer required\n>    to consume their input fully (not following this requirement used\n>    to result in intermittent errors in \"git push\").\n>\n>  * The pretty-format specifier \"%d\", which expands to \" (tagname)\"\n>    for a tagged commit, gained a cousin \"%D\" that just gives the\n>    \"tagname\" without frills.\n>\n>  * \"git push\" learned \"--signed\" push, that allows a push (i.e.\n>    request to update the refs on the other side to point at a new\n>    history, together with the transmission of necessary objects) to be\n>    signed, so that it can be verified and audited, using the GPG\n>    signature of the person who pushed, that the tips of branches at a\n>    public repository really point the commits the pusher wanted to,\n>    without having to \"trust\" the server.\n>\n>  * \"git interpret-trailers\" is a new filter to programmatically edit\n>    the tail end of the commit log messages, e.g. \"Signed-off-by:\".\n>\n>  * \"git help everyday\" shows the \"Everyday Git in 20 commands or so\"\n>    document, whose contents have been updated to match more modern\n>    Git practice.\n>\n>  * On the \"git svn\" front, work progresses to reduce memory consumption and\n>    to improve handling of mergeinfo.\n>\n>\n> Performance, Internal Implementation, Development Support etc.\n>\n>  * The API to manipulate the \"refs\" has been restructured to make it\n>    more transactional, with the eventual goal to allow all-or-none\n>    atomic updates and migrating the storage to something other than\n>    the traditional filesystem based one (e.g. databases).\n>\n>  * The lockfile API and its users have been cleaned up.\n>\n>  * We no longer attempt to keep track of individual dependencies to\n>    the header files in the build procedure, relying instead on automated\n>    dependency generation support from modern compilers.\n>\n>  * In tests, we have been using NOT_{MINGW,CYGWIN} test prerequisites\n>    long before negated prerequisites e.g. !MINGW were invented.\n>    The former has been converted to the latter to avoid confusion.\n>\n>  * Optimized looking up a remote's configuration in a repository with very many\n>    remotes defined.\n>\n>  * There are cases where you lock and open to write a file, close it\n>    to show the updated contents to an external processes, and then have\n>    to update the file again while still holding the lock; now the\n>    lockfile API has support for such an access pattern.\n>\n>  * The API to allocate the structure to keep track of commit\n>    decoration has been updated to make it less cumbersome to use.\n>\n>  * An in-core caching layer to let us avoid reading the same\n>    configuration files several times has been added.  A few commands\n>    have been converted to use this subsystem.\n>\n>  * Various code paths have been cleaned up and simplified by using\n>    the \"strbuf\", \"starts_with()\", and \"skip_prefix()\" APIs more.\n>\n>  * A few codepaths that died when large blobs that would not fit in\n>    core are involved in their operation have been taught to punt\n>    instead, by e.g. marking a too-large blob as not to be diffed.\n>\n>  * A few more code paths in \"commit\" and \"checkout\" have been taught\n>    to repopulate the cache-tree in the index, to help speed up later\n>    \"write-tree\" (used in \"commit\") and \"diff-index --cached\" (used in\n>    \"status\").\n>\n>  * A common programming mistake to assign the same short option name\n>    to two separate options is detected by the parse_options() API to help\n>    developers.\n>\n>  * The code path to write out the packed-refs file has been optimized,\n>    which especially matters in a repository with a large number of\n>    refs.\n>\n>  * The check to see if a ref $F can be created by making sure no\n>    existing ref has $F/ as its prefix has been optimized, which\n>    especially matters in a repository with a large number of existing\n>    refs.\n>\n>  * \"git fsck\" was taught to check the contents of tag objects a bit more.\n>\n>  * \"git hash-object\" was taught a \"--literally\" option to help\n>    debugging.\n>\n>  * When running a required clean filter, we do not have to mmap the\n>    original before feeding the filter.  Instead, stream the file\n>    contents directly to the filter and process its output.\n>\n>  * The scripts in the test suite can be run with the \"-x\" option to show\n>    a shell-trace of each command they run.\n>\n>  * The \"run-command\" API learned to manage the argv and environment\n>    arrays for child process, alleviating the need for the callers to\n>    allocate and deallocate them.\n>\n>  * Some people use AsciiDoctor, instead of AsciiDoc, to format our\n>    documentation set; the documentation has been adjusted to be usable\n>    by both, as AsciiDoctor is pickier than AsciiDoc about its input\n>    mark-up.\n>\n>\n> Also contains various documentation updates and code clean-ups.\n>\n>\n> Fixes since v2.1\n> ----------------\n>\n> Unless otherwise noted, all the fixes since v2.1 in the maintenance\n> track are contained in this release (see the maintenance releases'\n> notes for details).\n>\n>  * \"git log --pretty/format=\" with an empty format string did not\n>    mean the more obvious \"No output whatsoever\" but \"Use default\n>    format\", which was counterintuitive.\n>\n>  * \"git -c section.var command\" and \"git -c section.var= command\"\n>    should pass the configuration value differently (the former should be a\n>    boolean true, the latter should be an empty string).\n>\n>  * Applying a patch not generated by Git in a subdirectory used to\n>    check for whitespace breakage using the attributes of incorrect\n>    paths. Also whitespace checks were performed even for paths\n>    excluded via the \"git apply --exclude=<path>\" mechanism.\n>\n>  * \"git bundle create\" with a date-range specification was meant to\n>    exclude tags outside the range, but it didn't.\n>\n>  * \"git add x\" where x used to be a directory and is now a\n>    symbolic link to a directory misbehaved.\n>\n>  * The prompt script checked the $GIT_DIR/ref/stash file to see if there\n>    is a stash, which was a no-no.\n>\n>  * Pack-protocol documentation had a minor typo.\n>\n>  * \"git checkout -m\" did not switch to another branch while carrying\n>    the local changes forward when a path was deleted from the index.\n>\n>  * \"git daemon\" (with NO_IPV6 build configuration) used to incorrectly\n>    use the hostname even when gethostbyname() reported that the given\n>    hostname is not found.\n>    (merge 107efbe rs/daemon-fixes later to maint).\n>\n>  * With sufficiently long refnames, \"git fast-import\" could have\n>    overflowed an on-stack buffer.\n>\n>  * After \"pack-refs --prune\" packed refs at the top-level, it failed\n>    to prune them.\n>\n>  * Progress output from \"git gc --auto\" was visible in \"git fetch -q\".\n>\n>  * We used to pass -1000 to poll(2), expecting it to also mean \"no\n>    timeout\", which should be spelled as -1.\n>\n>  * \"git rebase\" documentation was unclear that it is required to\n>    specify on what <upstream> the rebase is to be done when telling it\n>    to first check out <branch>.\n>    (merge 95c6826 so/rebase-doc later to maint).\n>\n>  * \"git push\" over HTTP transport had an artificial limit on the number of\n>    refs that can be pushed, imposed by the command line length.\n>    (merge 26be19b jk/send-pack-many-refspecs later to maint).\n>\n>  * When receiving an invalid pack stream that records the same object\n>    twice, multiple threads got confused due to a race.\n>    (merge ab791dd jk/index-pack-threading-races later to maint).\n>\n>  * An attempt to remove the entire tree in the \"git fast-import\" input\n>    stream caused it to misbehave.\n>    (merge 2668d69 mb/fast-import-delete-root later to maint).\n>\n>  * Reachability check (used in \"git prune\" and friends) did not add a\n>    detached HEAD as a starting point to traverse objects still in use.\n>    (merge c40fdd0 mk/reachable-protect-detached-head later to maint).\n>\n>  * \"git config --add section.var val\" when section.var already has an\n>    empty-string value used to lose the empty-string value.\n>    (merge c1063be ta/config-add-to-empty-or-true-fix later to maint).\n>\n>  * \"git fsck\" failed to report that it found corrupt objects via its\n>    exit status in some cases.\n>    (merge 30d1038 jk/fsck-exit-code-fix later to maint).\n>\n>  * Use of the \"--verbose\" option used to break \"git branch --merged\".\n>    (merge 12994dd jk/maint-branch-verbose-merged later to maint).\n>\n>  * Some MUAs mangle a line in a message that begins with \"From \" to\n>    \">From \" when writing to a mailbox file, and feeding such an input\n>    to \"git am\" used to lose such a line.\n>    (merge 85de86a jk/mbox-from-line later to maint).\n>\n>  * \"rev-parse --verify --quiet $name\" is meant to quietly exit with a\n>    non-zero status when $name is not a valid object name, but still\n>    gave error messages in some cases.\n>\n>  * A handful of C source files have been updated to include\n>    \"git-compat-util.h\" as the first thing, to conform better to our\n>    coding guidelines.\n>    (merge 1c4b660 da/include-compat-util-first-in-c later to maint).\n>\n>  * The t7004 test, which tried to run Git with small stack space, has been\n>    updated to use a bit larger stack to avoid false breakage on some\n>    platforms.\n>    (merge b9a1907 sk/tag-contains-wo-recursion later to maint).\n>\n>  * A few documentation pages had example sections marked up not quite\n>    correctly, which passed AsciiDoc but failed with AsciiDoctor.\n>    (merge c30c43c bc/asciidoc-pretty-formats-fix later to maint).\n>    (merge f8a48af bc/asciidoc later to maint).\n>\n>  * \"gitweb\" used deprecated CGI::startfrom, which was removed from\n>    CGI.pm as of 4.04; use CGI::start_from instead.\n>    (merge 4750f4b rm/gitweb-start-form later to maint).\n>\n>  * Newer versions of 'meld' break the auto-detection we use to see if\n>    they are new enough to support the `--output` option.\n>    (merge b12d045 da/mergetool-meld later to maint).\n>\n>  * \"git pack-objects\" forgot to disable the codepath to generate the\n>    object reachability bitmap when it needs to split the resulting\n>    pack.\n>    (merge 2113471 jk/pack-objects-no-bitmap-when-splitting later to maint).\n>\n>  * The code to use cache-tree trusted the on-disk data too much and\n>    fell into an infinite loop upon seeing an incorrectly recorded\n>    index file.\n>    (merge 729dbbd jk/cache-tree-protect-from-broken-libgit2 later to maint).\n>\n>  * \"git fetch\" into a repository where branch B was deleted earlier,\n>    back when it had reflog enabled, and then branch B/C is fetched\n>    into it without reflog enabled, which is arguably an unlikely\n>    corner case, unnecessarily failed.\n>    (merge aae828b jk/fetch-reflog-df-conflict later to maint).\n>\n>  * \"git log --first-parent -L...\" used to crash.\n>    (merge a8787c5 tm/line-log-first-parent later to maint).\n\nI'm sad to report that I'm getting test failures with this release.\nBuilt from git and did 'make -C t prove NO_SVN_TESTS=1' and got this\nresult:\n\n$ make -j8\n$ make -C t prove NO_SVN_TESTS=1 PROVE=\"prove -j8\"\n[...]\nTest Summary Report\n-------------------\nt4202-log.sh                                     (Wstat: 256 Tests: 42 Failed: 2)\n  Failed tests:  41-42\n  Non-zero exit status: 1\nt5534-push-signed.sh                             (Wstat: 256 Tests: 7 Failed: 2)\n  Failed tests:  6-7\n  Non-zero exit status: 1\nt5801-remote-helpers.sh                          (Wstat: 256 Tests: 28 Failed: 2)\n  Failed tests:  21-22\n  Non-zero exit status: 1\nt6050-replace.sh                                 (Wstat: 256 Tests: 33 Failed: 4)\n  Failed tests:  30-33\n  Non-zero exit status: 1\nt6300-for-each-ref.sh                            (Wstat: 256 Tests: 134 Failed: 19)\n  Failed tests:  115-133\n  Non-zero exit status: 1\nt7510-signed-commit.sh                           (Wstat: 256 Tests: 10 Failed: 10)\n  Failed tests:  1-10\n  Non-zero exit status: 1\nt7612-merge-verify-signatures.sh                 (Wstat: 256 Tests: 6 Failed: 5)\n  Failed tests:  2-6\n  Non-zero exit status: 1\nt7600-merge.sh                                   (Wstat: 256 Tests: 49 Failed: 2)\n  Failed tests:  48-49\n  Non-zero exit status: 1\nt7004-tag.sh                                     (Wstat: 256 Tests: 136 Failed: 32)\n  Failed tests:  65-66, 69-72, 74-75, 77-100\n  Non-zero exit status: 1\nFiles=685, Tests=11975, 88 wallclock secs ( 3.97 usr  0.70 sys + 73.84 cusr 22.10 csys = 100.61 CPU)\nResult: FAIL\n\n\nI suspect that gnupg v2.1 is to blame somehow (I've had similar bad behavior\nwith my own projects using GPG in automation). Running through several of the\ngit tests shows that gpg is failing to sign:\n\n\n$ make -C t t7510-signed-commit GIT_TEST_OPTS=\"--verbose --debug\"\nmake: Entering directory '/home/snoonan/Development/git/t'\n*** t7510-signed-commit.sh ***\nInitialized empty Git repository in /home/snoonan/Development/git/t/trash directory.t7510-signed-commit/.git/\nexpecting success:\n[...]\ngpg: starting migration from earlier GnuPG versions\ngpg: porting secret keys from '/home/snoonan/Development/git/t/trash directory.t7510-signed-commit/gpghome/secring.gpg' to gpg-agent\ngpg: key CDDE430D: secret key imported\ngpg: key B7227189: secret key imported\ngpg: migration succeeded\ngpg: signing failed: Operation cancelled\ngpg: signing failed: Operation cancelled\nerror: gpg failed to sign the data\nfatal: failed to write commit object\ngpg: signing failed: Operation cancelled\ngpg: signing failed: Operation cancelled\nerror: gpg failed to sign the data\nfatal: failed to write commit object\nnot ok 1 - create signed commits\n\n\nIf I build and install the old gnupg v2.0.26 package, things are\nhappier:\n\n\n$ make -C t prove NO_SVN_TESTS=1 PROVE=\"prove -j8\"\n[...]\nAll tests successful.\nFiles=685, Tests=11975, 87 wallclock secs ( 4.02 usr  0.69 sys + 76.41 cusr 21.96 csys = 103.08 CPU)\nResult: PASS\n\n\nUsing Arch Linux on x86_64. Anyone else able to repro?\n"},{"id":"252652","messageId":"20141128044656.GA19456@peff.net","threadId":"38061","inReplyTo":"20141127213224.GA27443@dispater.uplinklabs.net","subject":"Re: [ANNOUNCE] Git v2.2.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-28T04:46:56Z","receivedAt":"2014-11-28T04:46:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[nit: when quoting in your replies, please trim quotes to a reasonable\n length]\n\nOn Thu, Nov 27, 2014 at 01:32:24PM -0800, Steven Noonan wrote:\n\n> I'm sad to report that I'm getting test failures with this release.\n> Built from git and did 'make -C t prove NO_SVN_TESTS=1' and got this\n> result:\n> [...]\n> I suspect that gnupg v2.1 is to blame somehow (I've had similar bad behavior\n> with my own projects using GPG in automation). Running through several of the\n> git tests shows that gpg is failing to sign:\n\nI can reproduce here on Debian by installing gnupg2 v2.1 from\nexperimental (this gets installed as /usr/bin/gpg2, so I had to tweak\nthe code to use \"gpg2\" by default). In my case, gpg2 repeatedly contacts\nthe gpg-agent and pops up X dialogs asking to unlock keyrings in the\ntest suite. Hitting \"cancel\" causes the tests to fail. Clicking \"OK\"\nwith an empty passphrase lets the test pass.\n\nThe good news is that it is similarly broken on git v2.1.0. So this\nisn't something we broke; it's the new version of gnupg2.\n\nIt's not clear to me whether this is a regression in gnupg, or if\nthere's some magic configuration setting we need to get the old\nbehavior. It seems like the new version is more aggressive in trying to\nuse the agent to get a passphrase, even though the keyrings in the test\nare unencrypted, and do not need any passphrase. Which sounds like a bug\nto me.\n\nYou might have some luck talking with the gnupg folks about this\npossible bug. As a simple reproduction, doing:\n\n  cd git/t/lib-gpg\n  export GNUPGHOME=$PWD\n  echo foo | gpg --sign -a\n\nworks fine with gnupg1, or earlier versions of gnupg2. But with gnupg\n2.1, it causes the agent to pop up a passphrase dialog.\n\n-Peff\n"},{"id":"252655","messageId":"54784503.80108@drmicha.warpmail.net","threadId":"38061","inReplyTo":"20141127213224.GA27443@dispater.uplinklabs.net","subject":"Re: [ANNOUNCE] Git v2.2.0","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2014-11-28T09:48:51Z","receivedAt":"2014-11-28T09:48:51Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Steven Noonan schrieb am 27.11.2014 um 22:32:\n\n> \n> I'm sad to report that I'm getting test failures with this release.\n> Built from git and did 'make -C t prove NO_SVN_TESTS=1' and got this\n> result:\n> \n> $ make -j8\n> $ make -C t prove NO_SVN_TESTS=1 PROVE=\"prove -j8\"\n> [...]\n> Test Summary Report\n> -------------------\n> t4202-log.sh                                     (Wstat: 256 Tests: 42 Failed: 2)\n>   Failed tests:  41-42\n>   Non-zero exit status: 1\n> t5534-push-signed.sh                             (Wstat: 256 Tests: 7 Failed: 2)\n>   Failed tests:  6-7\n>   Non-zero exit status: 1\n> t5801-remote-helpers.sh                          (Wstat: 256 Tests: 28 Failed: 2)\n>   Failed tests:  21-22\n>   Non-zero exit status: 1\n> t6050-replace.sh                                 (Wstat: 256 Tests: 33 Failed: 4)\n>   Failed tests:  30-33\n>   Non-zero exit status: 1\n> t6300-for-each-ref.sh                            (Wstat: 256 Tests: 134 Failed: 19)\n>   Failed tests:  115-133\n>   Non-zero exit status: 1\n> t7510-signed-commit.sh                           (Wstat: 256 Tests: 10 Failed: 10)\n>   Failed tests:  1-10\n>   Non-zero exit status: 1\n> t7612-merge-verify-signatures.sh                 (Wstat: 256 Tests: 6 Failed: 5)\n>   Failed tests:  2-6\n>   Non-zero exit status: 1\n> t7600-merge.sh                                   (Wstat: 256 Tests: 49 Failed: 2)\n>   Failed tests:  48-49\n>   Non-zero exit status: 1\n> t7004-tag.sh                                     (Wstat: 256 Tests: 136 Failed: 32)\n>   Failed tests:  65-66, 69-72, 74-75, 77-100\n>   Non-zero exit status: 1\n> Files=685, Tests=11975, 88 wallclock secs ( 3.97 usr  0.70 sys + 73.84 cusr 22.10 csys = 100.61 CPU)\n> Result: FAIL\n> \n> \n> I suspect that gnupg v2.1 is to blame somehow (I've had similar bad behavior\n> with my own projects using GPG in automation). Running through several of the\n> git tests shows that gpg is failing to sign:\n> \n> \n> $ make -C t t7510-signed-commit GIT_TEST_OPTS=\"--verbose --debug\"\n> make: Entering directory '/home/snoonan/Development/git/t'\n> *** t7510-signed-commit.sh ***\n> Initialized empty Git repository in /home/snoonan/Development/git/t/trash directory.t7510-signed-commit/.git/\n> expecting success:\n> [...]\n> gpg: starting migration from earlier GnuPG versions\n> gpg: porting secret keys from '/home/snoonan/Development/git/t/trash directory.t7510-signed-commit/gpghome/secring.gpg' to gpg-agent\n> gpg: key CDDE430D: secret key imported\n> gpg: key B7227189: secret key imported\n> gpg: migration succeeded\n> gpg: signing failed: Operation cancelled\n> gpg: signing failed: Operation cancelled\n> error: gpg failed to sign the data\n> fatal: failed to write commit object\n> gpg: signing failed: Operation cancelled\n> gpg: signing failed: Operation cancelled\n> error: gpg failed to sign the data\n> fatal: failed to write commit object\n> not ok 1 - create signed commits\n> \n> \n> If I build and install the old gnupg v2.0.26 package, things are\n> happier:\n> \n> \n> $ make -C t prove NO_SVN_TESTS=1 PROVE=\"prove -j8\"\n> [...]\n> All tests successful.\n> Files=685, Tests=11975, 87 wallclock secs ( 4.02 usr  0.69 sys + 76.41 cusr 21.96 csys = 103.08 CPU)\n> Result: PASS\n> \n> \n> Using Arch Linux on x86_64. Anyone else able to repro?\n> \n\nAre you running gnome_keyring_deamon by any chance? It think it runs by\ndefault in Gnome, claims to offer gpg_agent functionality but does not\nseem to do so fully. I.e., its presence may keep gpg2.1 from starting\nits own gpg-agent. But gpg2.1 (\"gnupg modern branch\") needs a new\ngpg-agent which knows how to handle secret keys for gpg2.1.\n\n(I may take a shot at trying, but I'm on Fedora - they're slow and\nspecial in all things gpg/crypto. And compiling gpg2.1 means compiling\nall the bits and pieces that monster consists of these days...)\n\nMichael\n"},{"id":"252666","messageId":"20141128165009.GA4728@peff.net","threadId":"38061","inReplyTo":"54784503.80108@drmicha.warpmail.net","subject":"tests do not work with gpg 2.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-28T16:50:10Z","receivedAt":"2014-11-28T16:50:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[updated subject, as this is not specific to the v2.2.0 release at all]\n\nOn Fri, Nov 28, 2014 at 10:48:51AM +0100, Michael J Gruber wrote:\n\n> Are you running gnome_keyring_deamon by any chance? It think it runs by\n> default in Gnome, claims to offer gpg_agent functionality but does not\n> seem to do so fully. I.e., its presence may keep gpg2.1 from starting\n> its own gpg-agent. But gpg2.1 (\"gnupg modern branch\") needs a new\n> gpg-agent which knows how to handle secret keys for gpg2.1.\n> \n> (I may take a shot at trying, but I'm on Fedora - they're slow and\n> special in all things gpg/crypto. And compiling gpg2.1 means compiling\n> all the bits and pieces that monster consists of these days...)\n\nI'm not running the gnome daemon (I do normally run gpg-agent, though),\nand I can reproduce.\n\nI wanted to try experimenting today with making sure GPG_AGENT_INFO was\nunset in the environment. But despite nothing changing (i.e., before I\neven cleared that variable), I'm getting totally different results.\n\nNow when I run t4202, I get no agent prompt, and just:\n\n    ok 40 - dotdot is a parent directory\n    \n    expecting success: \n            test_when_finished \"git reset --hard && git checkout master\" &&\n            git checkout -b signed master &&\n            echo foo >foo &&\n            git add foo &&\n            git commit -S -m signed_commit &&\n            git log --graph --show-signature -n1 signed >actual &&\n            grep \"^| gpg: Signature made\" actual &&\n            grep \"^| gpg: Good signature\" actual\n    \n    Switched to a new branch 'signed'\n    gpg: skipped \"C O Mitter <committer@example.com>\": No secret key\n    gpg: signing failed: No secret key\n    error: gpg failed to sign the data\n    fatal: failed to write commit object\n\nAnd then a subsequent run gives me:\n\n    rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/19D48118D24877F59C2AE86FEC8C3E90694B2631.key': Permission denied\n    rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/E0C803F8BC3BCC4990E174E05936A7636E888899.key': Permission denied\n    rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/FCFAC48BF12AC0FCC32B69AB90AA7B1891382C29.key': Permission denied\n    rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/D50A866904B91C0C49A3F6059584F4A09807D330.key': Permission denied\n    FATAL: Cannot prepare test area\n\nIt seems that it creates the private-keys directory without the 'x' bit:\n\n    $ ls -ld trash*/gpghome/private-keys-v1.d\n    drw------- 2 peff peff 4096 Nov 28 11:45 trash directory.t4202-log/gpghome/private-keys-v1.d/\n\nSo that's weird, and doubly so that it is behaving differently than it\nwas last night. Obviously _something_ must have change. Maybe something\nrelated to the state of my running agent, I guess.\n\n-Peff\n"},{"id":"252862","messageId":"547DB6C3.5010704@drmicha.warpmail.net","threadId":"38061","inReplyTo":"20141128165009.GA4728@peff.net","subject":"Re: tests do not work with gpg 2.1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2014-12-02T12:55:31Z","receivedAt":"2014-12-02T12:55:31Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King schrieb am 28.11.2014 um 17:50:\n> [updated subject, as this is not specific to the v2.2.0 release at all]\n> \n> On Fri, Nov 28, 2014 at 10:48:51AM +0100, Michael J Gruber wrote:\n> \n>> Are you running gnome_keyring_deamon by any chance? It think it runs by\n>> default in Gnome, claims to offer gpg_agent functionality but does not\n>> seem to do so fully. I.e., its presence may keep gpg2.1 from starting\n>> its own gpg-agent. But gpg2.1 (\"gnupg modern branch\") needs a new\n>> gpg-agent which knows how to handle secret keys for gpg2.1.\n>>\n>> (I may take a shot at trying, but I'm on Fedora - they're slow and\n>> special in all things gpg/crypto. And compiling gpg2.1 means compiling\n>> all the bits and pieces that monster consists of these days...)\n> \n> I'm not running the gnome daemon (I do normally run gpg-agent, though),\n> and I can reproduce.\n\nYou get the passphrase prompt, Steven didn't, if I understood correctly.\nYou can continue successfully by hitting OK, Steven coudn't hit anything...\n\n> I wanted to try experimenting today with making sure GPG_AGENT_INFO was\n> unset in the environment. But despite nothing changing (i.e., before I\n> even cleared that variable), I'm getting totally different results.\n> \n> Now when I run t4202, I get no agent prompt, and just:\n> \n>     ok 40 - dotdot is a parent directory\n>     \n>     expecting success: \n>             test_when_finished \"git reset --hard && git checkout master\" &&\n>             git checkout -b signed master &&\n>             echo foo >foo &&\n>             git add foo &&\n>             git commit -S -m signed_commit &&\n>             git log --graph --show-signature -n1 signed >actual &&\n>             grep \"^| gpg: Signature made\" actual &&\n>             grep \"^| gpg: Good signature\" actual\n>     \n>     Switched to a new branch 'signed'\n>     gpg: skipped \"C O Mitter <committer@example.com>\": No secret key\n>     gpg: signing failed: No secret key\n>     error: gpg failed to sign the data\n>     fatal: failed to write commit object\n\nThat is how things turned for Steven, afaik.\n\n> And then a subsequent run gives me:\n> \n>     rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/19D48118D24877F59C2AE86FEC8C3E90694B2631.key': Permission denied\n>     rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/E0C803F8BC3BCC4990E174E05936A7636E888899.key': Permission denied\n>     rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/FCFAC48BF12AC0FCC32B69AB90AA7B1891382C29.key': Permission denied\n>     rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/D50A866904B91C0C49A3F6059584F4A09807D330.key': Permission denied\n>     FATAL: Cannot prepare test area\n> \n> It seems that it creates the private-keys directory without the 'x' bit:\n> \n>     $ ls -ld trash*/gpghome/private-keys-v1.d\n>     drw------- 2 peff peff 4096 Nov 28 11:45 trash directory.t4202-log/gpghome/private-keys-v1.d/\n> \n> So that's weird, and doubly so that it is behaving differently than it\n> was last night. Obviously _something_ must have change. Maybe something\n> related to the state of my running agent, I guess.\n> \n> -Peff\n> \n\nI think if you unset GPG_AGENT_INFO, gpg2.1 thinks there is no agent,\nstarts it's own and talks to it via a socket directly (no env variable).\nNow that one seems come with different options (regarding pinentry) so\nthat it can't even ask you for a passphrase.\n\nThat private-keys directory is from the first run of gpg2.1 on a pre-2.1\nGPGHOME. It converts the old secring db to that new dir of entries and\nuses that instead.\n\nRegarding the umask: That may actually be fallout from\n\ne7f224f (t/lib-gpg: make gpghome files writable, 2014-10-24)\n\nwhere I didn't expect directories to be present in gpghome. Maybe i\nshould change\n\nchmod 0700 gpghome\nchmod 0600 gpghome/*\n\nto\n\nchmod -R o+w gpghome/\n\nthough I felt somehow safer with the explicit permissions.\n\nMichael\n"},{"id":"252865","messageId":"9c28f16c677bbc774e5b8dfc79b6ffe2c55d1720.1417527514.git.git@drmicha.warpmail.net","threadId":"38061","inReplyTo":"547DB6C3.5010704@drmicha.warpmail.net","subject":"[PATCH] t/lib-gpg: adjust permissions for gnupg 2.1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2014-12-02T13:40:27Z","receivedAt":"2014-12-02T13:40:27Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Before gnupg 2.1 (aka \"modern branch\"), gpghome would contain only files\nwhich allowed t/lib-gpg.sh to set permissions explicitely, and we did\nthat since\n28a1b07 (t/lib-gpg: adjust permissions for gnupg 2.1, 2014-12-02)\nin order to adjust wrong permissions from a checkout on ro file systems.\n\ngnupg 2.1 creates a new directory in gpghome which would get its x bit removed.\n\nAdjust and use +X so that any directory would get its x bit set. This\nalso keeps the x bit on files which had it set for whatever wrong\nreason, but we care only about having at least the necessary\npermissions for the tests to run.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\nSomething like this?\nUntested for lack of gpg2.1\n\n t/lib-gpg.sh | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/t/lib-gpg.sh b/t/lib-gpg.sh\nindex cd2baef..25ca12d 100755\n--- a/t/lib-gpg.sh\n+++ b/t/lib-gpg.sh\n@@ -17,8 +17,7 @@ else\n \t\t# Name and email: C O Mitter <committer@example.com>\n \t\t# No password given, to enable non-interactive operation.\n \t\tcp -R \"$TEST_DIRECTORY\"/lib-gpg ./gpghome\n-\t\tchmod 0700 gpghome\n-\t\tchmod 0600 gpghome/*\n+\t\tchmod -R u+rwX gpghome\n \t\tGNUPGHOME=\"$(pwd)/gpghome\"\n \t\texport GNUPGHOME\n \t\ttest_set_prereq GPG\n-- \n2.2.0.rc3.286.g888a711\n"},{"id":"252890","messageId":"20141202210753.GD23461@peff.net","threadId":"38061","inReplyTo":"9c28f16c677bbc774e5b8dfc79b6ffe2c55d1720.1417527514.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] t/lib-gpg: adjust permissions for gnupg 2.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-02T21:07:53Z","receivedAt":"2014-12-02T21:07:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2014 at 02:40:27PM +0100, Michael J Gruber wrote:\n\n> Before gnupg 2.1 (aka \"modern branch\"), gpghome would contain only files\n> which allowed t/lib-gpg.sh to set permissions explicitely, and we did\n> that since\n> 28a1b07 (t/lib-gpg: adjust permissions for gnupg 2.1, 2014-12-02)\n> in order to adjust wrong permissions from a checkout on ro file systems.\n\nI think this 28a1b07 is wrong. Did you mean e7f224f?\n\n> gnupg 2.1 creates a new directory in gpghome which would get its x bit removed.\n\nThanks for digging in this. The story is a little more tricky, though,\nand I do not think this patch is strictly necessary.\n\nWe copy lib-gpg/* to the trash directory, and only run gpg on it there.\nSo it is there that gpg2.1 will munge the files, _after_ we have\ncopied and done our chmod. And that works fine with the current code.\n\nThe problem came when I was trying to test/debug, and outside of the\ntests did \"cd lib-gpg && gpg2 ...\". That munged my lib-gpg directory,\nand the resulting breakage was copied into each subsequent trash\ndirectory.\n\nSo while your patch is not necessary, it is a nice defense against this\nsort of manual munging, or against future patches which add more\ndirectories. But...\n\n> Adjust and use +X so that any directory would get its x bit set. This\n> also keeps the x bit on files which had it set for whatever wrong\n> reason, but we care only about having at least the necessary\n> permissions for the tests to run.\n\nTaking a step back, though, I am not sure I understand the reasoning\nbehind the original e7f224f. The rationale in the commit message is that\nwe want to make sure that the files are writable. But why would they not\nbe? They are created by \"cp -R\", so unless your umask does not allow the\nowner to write to the files, they should be writable, no? And if your\numask is set that way, lots of things are going to break.\n\nAnd indeed, if I remove the chmods completely, like:\n\ndiff --git a/t/lib-gpg.sh b/t/lib-gpg.sh\nindex cd2baef..6ee4bb6 100755\n--- a/t/lib-gpg.sh\n+++ b/t/lib-gpg.sh\n@@ -17,8 +17,6 @@ else\n \t\t# Name and email: C O Mitter <committer@example.com>\n \t\t# No password given, to enable non-interactive operation.\n \t\tcp -R \"$TEST_DIRECTORY\"/lib-gpg ./gpghome\n-\t\tchmod 0700 gpghome\n-\t\tchmod 0600 gpghome/*\n \t\tGNUPGHOME=\"$(pwd)/gpghome\"\n \t\texport GNUPGHOME\n \t\ttest_set_prereq GPG\n\nthe tests run fine for me. What am I missing?\n\nI do think the original \"0700\" chmod _is_ useful, though. But not\nbecause it makes sure things are writable, but because it makes sure\nthat it is _not_ world-readable. GPG complains about the lax permissions\n(of course it does not know that the keyrings are not really secrets in\nthis case). However, this does not actually prevent the tests from\nrunning successfully.\n\nSo from my perspective, the simplest thing is to keep the original\n\"chmod 0700\" for that reason (or make it \"chmod go-rwx\", if you like),\nand drop the inner chmod completely (effectively reverting e7f224f). But\nagain, perhaps there is some case that it covers that I do not\nunderstand.\n\n-Peff\n"},{"id":"252891","messageId":"20141202212133.GE23461@peff.net","threadId":"38061","inReplyTo":"547DB6C3.5010704@drmicha.warpmail.net","subject":"Re: tests do not work with gpg 2.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-02T21:21:34Z","receivedAt":"2014-12-02T21:21:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2014 at 01:55:31PM +0100, Michael J Gruber wrote:\n\n> That private-keys directory is from the first run of gpg2.1 on a pre-2.1\n> GPGHOME. It converts the old secring db to that new dir of entries and\n> uses that instead.\n\nThanks for untangling this. As I mentioned elsewhere in the thread, it\nwas just that I had munged my parent lib-gpg directory. Cleaning that up\nfixed the problem I was seeing, and I could proceed with experimenting.\n\n> I think if you unset GPG_AGENT_INFO, gpg2.1 thinks there is no agent,\n> starts it's own and talks to it via a socket directly (no env variable).\n> Now that one seems come with different options (regarding pinentry) so\n> that it can't even ask you for a passphrase.\n\nIf I unset GPG_AGENT_INFO, I still get the original behavior; a pop-up\ndialog that asks for the passphrase (and feeding it the empty passphrase\nworks). My differing behavior from Steven may just be quirks in our\nsetup, or maybe it is the fact that I still have gpg1 installed.\n\nI think the fundamental problem, though, is just that gpg2.1 cannot\nseamlessly handle the case of a keyring with no passphrase. I am sure\nthis is not a well-tested case, since GPG devs likely would say \"you're\ndoing it wrong\". But obviously it makes sense here for testing purposes.\n\nI'm not sure if the most expedient path is trying to convince gpg\ndevelopers that it's a bug, or if there is some workaround (like\n\"--passphrase-file /dev/null\" or something).\n\nI've been using the patch below to test, and am tempted to offer it for\ninclusion. But if we need to hack up the gpg command-line just for the\ntests, then lib-gpg.sh would end up setting gpg.program, and that would\noverride what my patch is doing anyway.\n\n-- >8 --\nSubject: Makefile: provide build-time config of \"gpg\" program\n\nIf the user hasn't configured gpg.program, we fallback to\nrunning just \"gpg\". Since it _can_ be overridden by\nrun-time config, this is sufficient for most people who have\nsome specific \"gpg\" they want to run. However, there are two\nreasons we might want a build-time configuration, too:\n\n  1. A binary package may want to hard-code a matching gpg\n     without requiring that the user set up their PATH or\n     config explicitly.\n\n  2. When running the test scripts, it's hard to debug tests\n     using an alternate GPG, as it would involve tweaking\n     each individual test script to set the gpg path.\n\nLet's provide a Makefile knob for tweaking this.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n Makefile        | 6 ++++++\n gpg-interface.c | 2 +-\n 2 files changed, 7 insertions(+), 1 deletion(-)\n\ndiff --git a/Makefile b/Makefile\nindex 827006b..e3c1ec1 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -400,6 +400,7 @@ INSTALL = install\n RPMBUILD = rpmbuild\n TCL_PATH = tclsh\n TCLTK_PATH = wish\n+GPG_PATH = gpg\n XGETTEXT = xgettext\n MSGFMT = msgfmt\n PTHREAD_LIBS = -lpthread\n@@ -1503,6 +1504,10 @@ SHELL_PATH_CQ_SQ = $(subst ','\\'',$(SHELL_PATH_CQ))\n BASIC_CFLAGS += -DSHELL_PATH='$(SHELL_PATH_CQ_SQ)'\n endif\n \n+GPG_PATH_CQ = \"$(subst \",\\\",$(subst \\,\\\\,$(GPG_PATH)))\"\n+GPG_PATH_CQ_SQ = $(subst ','\\'',$(GPG_PATH_CQ))\n+BASIC_CFLAGS += -DGPG_PATH='$(GPG_PATH_CQ_SQ)'\n+\n GIT_USER_AGENT_SQ = $(subst ','\\'',$(GIT_USER_AGENT))\n GIT_USER_AGENT_CQ = \"$(subst \",\\\",$(subst \\,\\\\,$(GIT_USER_AGENT)))\"\n GIT_USER_AGENT_CQ_SQ = $(subst ','\\'',$(GIT_USER_AGENT_CQ))\n@@ -2038,6 +2043,7 @@ GIT-BUILD-OPTIONS: FORCE\n \t@echo SHELL_PATH=\\''$(subst ','\\'',$(SHELL_PATH_SQ))'\\' >$@\n \t@echo PERL_PATH=\\''$(subst ','\\'',$(PERL_PATH_SQ))'\\' >>$@\n \t@echo DIFF=\\''$(subst ','\\'',$(subst ','\\'',$(DIFF)))'\\' >>$@\n+\t@echo GPG_PATH=\\''$(subst ','\\'',$(subst ','\\'',$(GPG_PATH)))'\\' >>$@\n \t@echo PYTHON_PATH=\\''$(subst ','\\'',$(PYTHON_PATH_SQ))'\\' >>$@\n \t@echo TAR=\\''$(subst ','\\'',$(subst ','\\'',$(TAR)))'\\' >>$@\n \t@echo NO_CURL=\\''$(subst ','\\'',$(subst ','\\'',$(NO_CURL)))'\\' >>$@\ndiff --git a/gpg-interface.c b/gpg-interface.c\nindex 68b0c81..67c6e35 100644\n--- a/gpg-interface.c\n+++ b/gpg-interface.c\n@@ -5,7 +5,7 @@\n #include \"sigchain.h\"\n \n static char *configured_signing_key;\n-static const char *gpg_program = \"gpg\";\n+static const char *gpg_program = GPG_PATH;\n \n #define PGP_SIGNATURE \"-----BEGIN PGP SIGNATURE-----\"\n #define PGP_MESSAGE \"-----BEGIN PGP MESSAGE-----\"\n-- \n2.2.0.390.gf60752d\n"},{"id":"252892","messageId":"20141202213002.GA25338@peff.net","threadId":"38061","inReplyTo":"20141202212133.GE23461@peff.net","subject":"Re: tests do not work with gpg 2.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-02T21:30:03Z","receivedAt":"2014-12-02T21:30:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2014 at 04:21:33PM -0500, Jeff King wrote:\n\n> I'm not sure if the most expedient path is trying to convince gpg\n> developers that it's a bug, or if there is some workaround (like\n> \"--passphrase-file /dev/null\" or something).\n> \n> I've been using the patch below to test, and am tempted to offer it for\n> inclusion. But if we need to hack up the gpg command-line just for the\n> tests, then lib-gpg.sh would end up setting gpg.program, and that would\n> override what my patch is doing anyway.\n\nSo...I tried that. So many things went wrong. :)\n\nFor one thing, the build-time GPG_PATH patch I posted is not quite\nenough. We would probably want to pass it down to the test scripts, too,\nas they run \"gpg --version\" to figure out whether we have gpg or not.\n\nSecondly, you cannot set gpg.program to \"gpg2 --passphrase-file\n/dev/null\", because we do not use the shell to exec gpg.program. This is\nunlike most of the rest of git-spawned programs, but of course changing\nit has compatibility problems. We'd probably want gpg.command or\nsomething as an alternative.\n\nAnd finally, after convincing git to really use \"--passphrase-file\", I\nfind that it does not fix the problem at all. GPG still insists on\nopening an agent window. Nor does \"--batch\" help.\n\nSo I dunno. Maybe there is some clever way to work around it, but I do\nnot know it.\n\n-Peff\n"},{"id":"252898","messageId":"xmqqiohtli4h.fsf@gitster.dls.corp.google.com","threadId":"38061","inReplyTo":"20141202210753.GD23461@peff.net","subject":"Re: [PATCH] t/lib-gpg: adjust permissions for gnupg 2.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-02T23:57:50Z","receivedAt":"2014-12-02T23:57:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Taking a step back, though, I am not sure I understand the reasoning\n> behind the original e7f224f. The rationale in the commit message is that\n> we want to make sure that the files are writable. But why would they not\n> be? They are created by \"cp -R\",...\n\nWait.  After doing this,\n\n    $ mkdir -p src/a && >src/b 2>src/a/c && chmod a-w src/b src/a/c\n    $ cp -R src dst\n    $ ls -lR dst\n\ndst/b and dst/a/c are 0440 (with umask 0027, which makes src/b and\nsrc/a/c also 0440, which is copied with \"cp -R\").\n\nI was primarily worried about t/lib-gpg/* being read-only from a\nsrc-tarball extract when we had a discussion that led to e7f224f7\n(t/lib-gpg: make gpghome files writable, 2014-10-24).\n"},{"id":"252900","messageId":"20141203000553.GA28969@peff.net","threadId":"38061","inReplyTo":"xmqqiohtli4h.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] t/lib-gpg: adjust permissions for gnupg 2.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-03T00:05:53Z","receivedAt":"2014-12-03T00:05:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2014 at 03:57:50PM -0800, Junio C Hamano wrote:\n\n> Wait.  After doing this,\n> \n>     $ mkdir -p src/a && >src/b 2>src/a/c && chmod a-w src/b src/a/c\n>     $ cp -R src dst\n>     $ ls -lR dst\n> \n> dst/b and dst/a/c are 0440 (with umask 0027, which makes src/b and\n> src/a/c also 0440, which is copied with \"cp -R\").\n\nWho is running that chmod and why? I know you are trying to simulate\n\"somehow they lost their 'w' bit\" here, but what is that \"somehow\"?\n\nGit does not track write-bits. So any git checkout should always have\nthe bit set, no? And likewise would any tarball generated by\ngit-archive. Does tar lose it on extraction? I would not think it would\ndo so, short of a broken umask.\n\nConfused...\n\n-Peff\n"},{"id":"252940","messageId":"547EF2B8.3020106@drmicha.warpmail.net","threadId":"38061","inReplyTo":"20141202210753.GD23461@peff.net","subject":"Re: [PATCH] t/lib-gpg: adjust permissions for gnupg 2.1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2014-12-03T11:23:36Z","receivedAt":"2014-12-03T11:23:36Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King schrieb am 02.12.2014 um 22:07:\n> On Tue, Dec 02, 2014 at 02:40:27PM +0100, Michael J Gruber wrote:\n> \n>> Before gnupg 2.1 (aka \"modern branch\"), gpghome would contain only files\n>> which allowed t/lib-gpg.sh to set permissions explicitely, and we did\n>> that since\n>> 28a1b07 (t/lib-gpg: adjust permissions for gnupg 2.1, 2014-12-02)\n>> in order to adjust wrong permissions from a checkout on ro file systems.\n> \n> I think this 28a1b07 is wrong. Did you mean e7f224f?\n\nOuch, I'm afraid I got that from my copy of the commit. After all, there\nis some truth in the patch/apply vs. push/pull-merge workflow discussion...\n\n>> gnupg 2.1 creates a new directory in gpghome which would get its x bit removed.\n> \n> Thanks for digging in this. The story is a little more tricky, though,\n> and I do not think this patch is strictly necessary.\n> \n> We copy lib-gpg/* to the trash directory, and only run gpg on it there.\n> So it is there that gpg2.1 will munge the files, _after_ we have\n> copied and done our chmod. And that works fine with the current code.\n\nRight. I should'nt draft patches when I don't have gpg2.1...\n\n> The problem came when I was trying to test/debug, and outside of the\n> tests did \"cd lib-gpg && gpg2 ...\". That munged my lib-gpg directory,\n> and the resulting breakage was copied into each subsequent trash\n> directory.\n> \n> So while your patch is not necessary, it is a nice defense against this\n> sort of manual munging, or against future patches which add more\n> directories. But...\n> \n>> Adjust and use +X so that any directory would get its x bit set. This\n>> also keeps the x bit on files which had it set for whatever wrong\n>> reason, but we care only about having at least the necessary\n>> permissions for the tests to run.\n> \n> Taking a step back, though, I am not sure I understand the reasoning\n> behind the original e7f224f. The rationale in the commit message is that\n> we want to make sure that the files are writable. But why would they not\n> be? They are created by \"cp -R\", so unless your umask does not allow the\n> owner to write to the files, they should be writable, no? And if your\n> umask is set that way, lots of things are going to break.\n\nIIRC: We had reports about some ro checkouts where the tests went wrong.\nI.e., the git.git checkout was on a ro file system, and the cp somehow\ncreated ro files in the tmp. Or was it the archive/pax issue?\n\nIn any case, we need writable gpghome (and contents), and the original\npatch ensured that.\n\n> And indeed, if I remove the chmods completely, like:\n> \n> diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh\n> index cd2baef..6ee4bb6 100755\n> --- a/t/lib-gpg.sh\n> +++ b/t/lib-gpg.sh\n> @@ -17,8 +17,6 @@ else\n>  \t\t# Name and email: C O Mitter <committer@example.com>\n>  \t\t# No password given, to enable non-interactive operation.\n>  \t\tcp -R \"$TEST_DIRECTORY\"/lib-gpg ./gpghome\n> -\t\tchmod 0700 gpghome\n> -\t\tchmod 0600 gpghome/*\n>  \t\tGNUPGHOME=\"$(pwd)/gpghome\"\n>  \t\texport GNUPGHOME\n>  \t\ttest_set_prereq GPG\n> \n> the tests run fine for me. What am I missing?\n\nYou messed with the wrong parts in gpghome :)\n\n> I do think the original \"0700\" chmod _is_ useful, though. But not\n> because it makes sure things are writable, but because it makes sure\n> that it is _not_ world-readable. GPG complains about the lax permissions\n> (of course it does not know that the keyrings are not really secrets in\n> this case). However, this does not actually prevent the tests from\n> running successfully.\n> \n> So from my perspective, the simplest thing is to keep the original\n> \"chmod 0700\" for that reason (or make it \"chmod go-rwx\", if you like),\n> and drop the inner chmod completely (effectively reverting e7f224f). But\n> again, perhaps there is some case that it covers that I do not\n> understand.\n> \n> -Peff\n> \n\nI would say the \"modern branch\" of gpg2.1 is still a bit unstable. If\nthe tests do run with it (as they seem to do, unless you mess with the\nsource of the cp) there are no permission fixes to do.\n\nOrthogonal to that is the pinentry issue: I haven't checked whether\ngpg2.1 asking for passphrases on passphrase-less secure keys is to be\nfixed on the gpg side. If yes, I would just wait for that since gpg2.1\nis not common yet.\n\nIf not, we should provide (in gpg config) an alternative pinentry that\njust returns an empty passphrase without bugging the user.\n\nMichael\n"},{"id":"252953","messageId":"xmqqsigwk8lj.fsf@gitster.dls.corp.google.com","threadId":"38061","inReplyTo":"20141203000553.GA28969@peff.net","subject":"Re: [PATCH] t/lib-gpg: adjust permissions for gnupg 2.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-03T16:21:12Z","receivedAt":"2014-12-03T16:21:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Dec 02, 2014 at 03:57:50PM -0800, Junio C Hamano wrote:\n>\n>> Wait.  After doing this,\n>> \n>>     $ mkdir -p src/a && >src/b 2>src/a/c && chmod a-w src/b src/a/c\n>>     $ cp -R src dst\n>>     $ ls -lR dst\n>> \n>> dst/b and dst/a/c are 0440 (with umask 0027, which makes src/b and\n>> src/a/c also 0440, which is copied with \"cp -R\").\n>\n> Who is running that chmod and why? I know you are trying to simulate\n> \"somehow they lost their 'w' bit\" here, but what is that \"somehow\"?\n\nThe very first thing I do after downloading and extracting a tarball\nfor any random project, before doing configure or make, is to a-w on\nits files (but not directories, as I typically build in-place in the\nsource tree even for projects that support VPATH build).\n\nSome ill-mannered projects' build break with this by trying to munge\ntheir own source files.  They are, well, badly written, and I would\nwant to know about them, and that is one of the reasons behind a-w.\n\nI do not know how widespread the practice is, but that was what I\ndid for this project, too, when I tried out Linus's first version\n;-) These days, I do \"git init && git add .\" instead, so it does not\nmatter to me personally, but \"cp -R\" we do will matter to people who\nstill care without fixing the mode bits of the copied ones that we\nintend to modify inside our tests and build procedure.\n"},{"id":"252954","messageId":"xmqqoarkk7gy.fsf@gitster.dls.corp.google.com","threadId":"38061","inReplyTo":"547EF2B8.3020106@drmicha.warpmail.net","subject":"Re: [PATCH] t/lib-gpg: adjust permissions for gnupg 2.1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-03T16:45:33Z","receivedAt":"2014-12-03T16:45:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Orthogonal to that is the pinentry issue: I haven't checked whether\n> gpg2.1 asking for passphrases on passphrase-less secure keys is to be\n> fixed on the gpg side. If yes, I would just wait for that since gpg2.1\n> is not common yet.\n>\n> If not, we should provide (in gpg config) an alternative pinentry that\n> just returns an empty passphrase without bugging the user.\n\nSounds like a sensible plan to me.  Thanks.\n"}]}