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

109 lines
3.5 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)
* various git-gui updates including new translations, wm states, etc.
(portability)
(performance)
(usability, bells and whistles)
* The object replace mechanism can be bypassed with --no-replace-objects
global option given to the "git" program.
* "git bisect reset" can reset to an arbitrary commit.
* "git checkout frotz" when there is no local branch "frotz" but there
is only one remote tracking branch "frotz" is taken as a request to
start the named branch at the corresponding remote tracking branch.
* "git describe" can be told to add "-dirty" suffix with "--dirty" option.
* "git diff" learned --submodule option to show a list of one-line logs
instead of differences between the commit object names.
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.
* "--pretty=format" option to "log" family of commands learned:
. to wrap text with the "%w()" specifier.
. to show reflog information with "%g[sdD]" specifier.
* "git merge" (and "git pull") learned --ff-only option to make it fail
if the merge does not result in a fast-forward.
* "git mergetool" learned to use p4merge.
* "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.
* "git svn" learned to read SVN 1.5+ and SVK merge tickets.
* 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.
---
exec >/var/tmp/1
echo O=$(git describe master)
O=v1.6.5.3-152-g122d0f6
git shortlog --no-merges $O..master --not maint