+Notes on behaviour change
+-------------------------
+
+ * 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.
+
+Preparing yourselves for compatibility issues in 1.7.0
+------------------------------------------------------
+
+In git 1.7.0, which is planned to be the release after 1.6.6, there will
+be a handful of behaviour changes that will break backward compatibility.
+
+These changes were discussed long time ago and existing behaviours have
+been identified as more problematic to the userbase than keeping them for
+the sake of backward compatibility.
+
+When necessary, transition strategy for existing users has been designed
+not to force them running around setting configuration variables and
+updating their scripts in order to keep the traditional behaviour on the
+day their sysadmin decides to install the new version of git. When we
+switched from "git-foo" to "git foo" in 1.6.0, even though the change had
+been advertised and the transition guide had been provided for a very long
+time, the users procrastinated during the entire transtion period, and
+ended up panicking on the day their sysadmins updated their git.
+
+For changes decided to be in 1.7.0, we have been much louder to strongly
+discourage such procrastination. If you have been using recent versions
+of git, you would have already seen warnings issued when you exercised
+features whose behaviour will change, with the instruction on how to keep
+the existing behaviour if you choose to. You hopefully should be well
+prepared already.
+
+Of course, we have also given "this and that will change in 1.7.0; prepare
+yourselves" warnings in the release notes and announcement messages.
+Let's see how well users will fare this time.
+
+ * "git push" into a branch that is currently checked out (i.e. pointed by
+ HEAD in a repository that is not bare) will be refused by default.
+
+ Similarly, "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.
+
+ Setting the configuration variables receive.denyCurrentBranch and
+ receive.denyDeleteCurrent to 'ignore' in the receiving repository
+ can be used to override these safety features. Versions of git
+ since 1.6.2 have issued a loud warning when you tried to do them
+ without setting the configuration, so repositories of people who
+ still need to be able to perform such a push should already been
+ future proofed.
+
+ 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 process that already took place so far.
+
+ * "git send-email" will not make deep threads by default when sending a
+ patch series with more than two messages. All messages will be sent as
+ a reply to the first message, i.e. cover letter. It has been possible
+ to configure send-email to do this by setting sendemail.chainreplyto
+ configuration variable to false. The only thing the new release will
+ do is to change the default when you haven't configured that variable.
+
+ * "git status" will not be "git commit --dry-run". This change does not
+ affect you if you run the command without pathspec.
+
+ Nobody sane found the current behaviour of "git status Makefile" useful
+ nor meaningful, and it confused users. "git commit --dry-run" has been
+ provided as a way to get the current behaviour of this command since
+ 1.6.5.
+
+ * "git diff" traditionally treated various "ignore whitespace" options
+ only as a way to filter the patch output. "git diff --exit-code -b"
+ exited with non-zero status even if all changes were about changing the
+ ammount of whitespace and nothing else. and "git diff -b" showed the
+ "diff --git" header line for such a change without patch text.
+
+ In 1.7.0, the "ignore whitespaces" will affect the semantics of the
+ diff operation itself. A change that does not affect anything but
+ whitespaces will be reported with zero exit status when run with
+ --exit-code, and there will not be "diff --git" header for such a
+ change.