git-commit-vandalism/Documentation/RelNotes-1.6.6.txt

109 lines
3.9 KiB
Plaintext
Raw Normal View History

GIT v1.6.6 Release Notes
========================
fsck: default to "git fsck --full" Linus and other git developers from the early days trained their fingers to type the command, every once in a while even without thinking, to check the consistency of the repository back when the lower core part of the git was still being developed. Developers who wanted to make sure that git correctly dealt with packfiles could deliberately trigger their creation and checked them after they were created carefully, but loose objects are the ones that are written by various commands from random codepaths. It made some technical sense to have a mode that checked only loose objects from the debugging point of view for that reason. Even for git developers, there no longer is any reason to type "git fsck" every five minutes these days, worried that some newly created objects might be corrupt due to recent change to git. The reason we did not make "--full" the default is probably we trust our filesystems a bit too much. At least, we trusted filesystems more than we trusted the lower core part of git that was under development. Once a packfile is created and we always use it read-only, there didn't seem to be much point in suspecting that the underlying filesystems or disks may corrupt them in such a way that is not caught by the SHA-1 checksum over the entire packfile and per object checksum. That trust in the filesystems might have been a good tradeoff between fsck performance and reliability on platforms git was initially developed on and for, but it may not be true anymore as we run on many more platforms these days. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-20 20:46:55 +02:00
In this release, "git fsck" defaults to "git fsck --full" and checks
packfiles, and because of this it will take much longer to complete
than before. If you prefer a quicker check only on loose objects (the
old default), you can say "git fsck --no-full". This has been
supported by 1.5.4 and newer versions of git, so it is safe to write
it in your script even if you use slightly older git on some of your
machines.
In git 1.7.0, which is planned to be the release after 1.6.6, "git
push" into a branch that is currently checked out will be refused by
default.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyCurrentBranch in the receiving
repository.
Also, "git push $there :$killed" to delete the branch $killed in a remote
repository $there, when $killed branch is the current branch pointed at by
its HEAD, will be refused by default.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyDeleteCurrent in the receiving
repository.
To ease the transition plan, the receiving repository of such a
push running this release will issue a big warning when the
configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition plan.
Updates since v1.6.5
--------------------
(subsystems)
(portability)
(performance)
(usability, bells and whistles)
* The object replace mechanism can be bypassed with --no-replace-objects
global option given to the "git" program.
fsck: default to "git fsck --full" Linus and other git developers from the early days trained their fingers to type the command, every once in a while even without thinking, to check the consistency of the repository back when the lower core part of the git was still being developed. Developers who wanted to make sure that git correctly dealt with packfiles could deliberately trigger their creation and checked them after they were created carefully, but loose objects are the ones that are written by various commands from random codepaths. It made some technical sense to have a mode that checked only loose objects from the debugging point of view for that reason. Even for git developers, there no longer is any reason to type "git fsck" every five minutes these days, worried that some newly created objects might be corrupt due to recent change to git. The reason we did not make "--full" the default is probably we trust our filesystems a bit too much. At least, we trusted filesystems more than we trusted the lower core part of git that was under development. Once a packfile is created and we always use it read-only, there didn't seem to be much point in suspecting that the underlying filesystems or disks may corrupt them in such a way that is not caught by the SHA-1 checksum over the entire packfile and per object checksum. That trust in the filesystems might have been a good tradeoff between fsck performance and reliability on platforms git was initially developed on and for, but it may not be true anymore as we run on many more platforms these days. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-20 20:46:55 +02:00
* "git fsck" by default checks the packfiles (i.e. "--full" is the
default); you can turn it off with "git fsck --no-full".
* import-tars contributed fast-import frontend learned more types of
compressed tarballs.
* "git instaweb" knows how to talk with mod_cgid to apache2.
* "git log --decorate" shows the location of HEAD as well.
* "git rebase -i" learned "reword" that acts like "edit" but immediately
starts an editor to tweak the log message without returning control to
the shell, which is done by "edit" to give an opportunity to tweak the
contents.
* Author names shown in gitweb output are links to search commits by the
author.
(developers)
Fixes since v1.6.5
------------------
All of the fixes in v1.6.5.X maintenance series are included in this
release, unless otherwise noted.
* "git apply" and "git diff" (including patch output from "git log -p")
now flags trailing blank lines as whitespace errors correctly (only
"apply --whitespace=fix" stripped them but "apply --whitespace=warn"
did not even warn).
* Two whitespace error classes, 'blank-at-eof' and 'blank-at-eol', have
been introduced (settable by core.whitespace configuration variable and
whitespace attribute). The 'trailing-space' whitespace error class has
become a short-hand to cover both of these and there is no behaviour
change for existing set-ups.
* "git cvsimport" did not work well when it is fed filenames from the
command line and is not started at the top of the work tree. We should
backport this by merging f6fdbb6 (cvsimport: fix relative argument
filenames, 2009-10-19).
* The way gitweb escapes its CGI parameters were broken especially when
the parameter was a UTF-8 string. We may want to backport this to
1.6.5.X series by merging 452e225 (gitweb: fix esc_param, 2009-10-13).
* gitweb used to show 'patch' link for merge commits but the output from
it is not usable to feed "git am" with. We may want to backport this
to 1.6.5.X series by merging 1655c98 (gitweb: Do not show 'patch' link
for merge commits, 2009-10-09).
---
exec >/var/tmp/1
echo O=$(git describe master)
O=v1.6.5.2-73-g9b12444
git shortlog --no-merges $O..master --not maint