| Release notes for Gerrit 2.5.2 |
| ============================== |
| |
| Gerrit 2.5.2 is now available: |
| |
| link:http://code.google.com/p/gerrit/downloads/detail?name=gerrit-full-2.5.2.war[http://code.google.com/p/gerrit/downloads/detail?name=gerrit-full-2.5.2.war] |
| |
| There are no schema changes from 2.5, or 2.5.1. |
| |
| However, if upgrading from a version older than 2.5, follow the upgrade |
| procedure in the 2.5 link:ReleaseNotes-2.5.html[Release Notes]. |
| |
| Bug Fixes |
| --------- |
| * Improve performance of ReceiveCommits for repos with many refs |
| + |
| When validating the received commits all existing refs were added as |
| uninteresting to the RevWalk. This resulted in bad performance when a |
| repository had many refs (>100000). Putting existing 'refs/changes/' |
| or 'refs/tags/' into the RevWalk is now avoided, which improves the |
| performance. |
| |
| * Improve Push performance by discarding 'cache-automerge/*' refs |
| early in VisibleRefFilter |
| + |
| For a typical large Git repository, with many refs and lots of cached |
| merges, the push time goes down significantly. |
| |
| * Don't display all files from a merge-commit when auto-merge fails |
| + |
| For merge commits Gerrit shows the difference to the automatic merge |
| result. The creation of the auto-merge result may fail, e.g. when the |
| merge commit has multiple merge bases (because JGit doesn't support |
| this case yet). In this case Gerrit was showing all files from the |
| merge commit. This caused several issues: |
| + |
| -- |
| ** the file list was too large for projects with a large number of |
| files |
| ** Gerrit would send too many false notification emails to users |
| watching changes under certain paths |
| ** both client and server needed a lot of resources in order to handle |
| such a large list of files |
| -- |
| + |
| Now the file list for a merge commit will be empty when the creation |
| of the auto-merge result fails. |
| |
| * link:http://code.google.com/p/gerrit/issues/detail?id=1726[issue 1726]: |
| Create ref for new patch set on direct push |
| + |
| If a change is in review and a new commit that has the Change-Id of |
| this change in its commit message is pushed directly, then a new patch |
| set for this commit is created and the change gets automatically |
| closed. The problem was that no change ref for this new patch set was |
| created and as result the change ref that was shown for the new patch |
| set in the WebUI, and which was contained in the patchset-created |
| event, was invalid. |
| |
| * link:http://code.google.com/p/gerrit/issues/detail?id=1767[issue 1767]: |
| Remove wrong error message when pushing a new ref fails |
| + |
| If pushing a new ref was rejected because the user was not allowed to |
| create it the error message always told the user that he's missing the |
| 'Create Reference' access right. This message was incorrect in some |
| cases. Users that have the 'Create Reference' access right assigned |
| are e.g. not allowed to create the ref if: |
| + |
| -- |
| ** they are pushing an annotated tag without having the |
| 'Push Annotated Tag' access right |
| ** they are pushing a signed tag without having the 'Push Signed Tag' |
| access right |
| ** the project state is set to 'Read Only' |
| -- |
| + |
| Now the error message just says 'Prohibited by Gerrit'. This generic |
| error message is better than a more concrete error message which is |
| wrong in same cases because a wrong message is misleading and |
| confuses the user. |
| + |
| In addition the description of the 'Prohibited by Gerrit' error in the |
| documentation has been updated to explain some additional cases in |
| which the 'Prohibited by Gerrit' error occurs. |
| |
| * link:http://code.google.com/p/gerrit/issues/detail?id=1444[issue 1444]: |
| Remove 'Mailing-List' header from sent emails |
| + |
| The non-standard 'Mailing-List' header that is included in the emails |
| sent by Gerrit isn't allowed by the Amazon Simple Email Service and is |
| now removed. |
| |
| * Improve SMTP client error messages |
| + |
| The wording of the error messages in the SMTP client was changed to |
| make it more clear at exactly what stage in the SMTP transaction the |
| server returned an error. Also the server's response text is now |
| always included. |
| + |
| In addition it is now ensured that already rejected recipients are |
| included in the error message when the server rejects the DATA |
| command. Without this there is no way of debugging rejected |
| recipients if all recipients are rejected since that typically |
| results in a DATA command rejection. Because some SMTP servers (e.g. |
| Postfix with the default configuration) delay rejection of HELO/EHLO |
| and MAIL FROM commands to the RCPT TO stage, this can happen not only |
| for bad recipients. |
| |
| * Allow time unit variables to be '0' |
| + |
| link:http://gerrit-documentation.googlecode.com/svn/Documentation/2.5/config-gerrit.html[ |
| Gerrit Configuration parameters] that expect a numerical time unit as |
| value can now be set to '0'. |
| |
| * link:http://code.google.com/p/gerrit/issues/detail?id=1076[issue 1076]: |
| Fix CLA hyperlink on account registration page |
| + |
| The New Contributor Agreement hyperlink on the Account Registration page |
| was malformed. |
| |
| * Fix broken link to repo command reference |
| + |
| The link to the repo command reference in the 'repo upload' section of |
| the 'Uploading Changes' documentation was broken. |
| |
| * link:http://code.google.com/p/gerrit/issues/detail?id=1569[issue 1569]: |
| Fix unexpected behaviour in the commit-msg hook caused by `GREP_OPTIONS` |
| + |
| If `GREP_OPTIONS` was set, it caused unexpected behaviour in the |
| commit-msg hook. For example if it included a setting like |
| `--exclude=".git/*"` it caused a new `Change-Id` line to be appended |
| to the commit message on every amend. |
| + |
| `GREP_OPTIONS` is now unset at the beginning of the commit-msg script |
| to prevent such problems from occurring. |
| + |
| The `GREP_OPTIONS` setting in the user's environment is unaffected |
| by this change. |