Pages

Thursday, February 7, 2013

Git 1.8.1.3


Another release to give fixes for a handful bugs to users who are stuck with the maintenance track ;-)  This maintenance release contains the following fixes, and other fixes to the documentation.
  • The attribute mechanism didn't allow limiting attributes to be applied to only a single directory itself with "path/" like the exclude mechanism does. The fix for this in 1.8.1.2 had performance degradation.
  • Command line completion code was inadvertently made incompatible with older versions of bash by using a newer array notation.
  • Scripts to test bash completion was inherently flaky as it was affected by whatever random things the user may have on $PATH.
  • A fix was added to the build procedure to work around buggy versions of ccache broke the auto-generation of dependencies, which unfortunately is still relevant because some people use ancient distros.
  • We used to stuff "user@" and then append what we read from /etc/mailname to come up with a default e-mail ident, but a bug lost the "user@" part.
  • "git am" did not parse datestamp correctly from Hg generated patch, when it is run in a locale outside C (or en).
  • Attempt to "branch --edit-description" an existing branch, while being on a detached HEAD, errored out.
  • "git cherry-pick" did not replay a root commit to an unborn branch.
  • We forgot to close the file descriptor reading from "gpg" output, killing "git log --show-signature" on a long history.
  • "git rebase --preserve-merges" lost empty merges in recent versions of Git.
  • Rebasing the history of superproject with change in the submodule has been broken since v1.7.12.
  • A failure to push due to non-ff while on an unborn branch dereferenced a NULL pointer when showing an error message.
For those of you who may not be familiar with how Git development works, these fixes were developed and reviewed on our mailing list (git@vger.kernel.org), and were first applied to the next branch of the main repository where developers and testers regularly pull from. They build and use the version from this branch daily to help ensuring the stability and correctness of the changes.

These changes proved to be safe after a few weeks testing period. And then they were merged to the master branch to become a part of upcoming release (1.8.2, scheduled to happen sometime in February).

Thanks to this fairly conservative development process, you can generally expect that the tip of our master branch is more stable than any released version of Git.

There are, however, people who want to avoid disruptive changes by staying behind, and to satisfy these people, among the changes that have been applied to the master branch, only the ones that are bugfixes (not feature enhancements) are merged from time to time to the maint branch and the results are tagged as maintenance releases.

This 1.8.1.3 is such a release.

No comments:

Post a Comment