Update draft release notes to 1.6.6 before merging topics for -rc1

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/RelNotes-1.6.6.txt

@@ -1,39 +1,97 @@
 Git v1.6.6 Release Notes
 ========================
 
-In this release, "git fsck" defaults to "git fsck --full" and checks
+Notes on behaviour change
-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
+ * In this release, "git fsck" defaults to "git fsck --full" and
-push" into a branch that is currently checked out will be refused by
+   checks packfiles, and because of this it will take much longer to
-default.
+   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.
 
-You can choose what should happen upon such a push by setting the
+Preparing yourselves for compatibility issues in 1.7.0
-configuration variable receive.denyCurrentBranch in the receiving
+------------------------------------------------------
-repository.
 
-Also, "git push $there :$killed" to delete the branch $killed in a remote
+In git 1.7.0, which is planned to be the release after 1.6.6, there will
-repository $there, when $killed branch is the current branch pointed at by
+be a handful of behaviour changes that will break backward compatibility.
-its HEAD, will be refused by default.
 
-You can choose what should happen upon such a push by setting the
+These changes were discussed long time ago and existing behaviours have
-configuration variable receive.denyDeleteCurrent in the receiving
+been identified as more problematic to the userbase than keeping them for
-repository.
+the sake of backward compatibility.
 
-To ease the transition plan, the receiving repository of such a
+When necessary, transition strategy for existing users has been designed
-push running this release will issue a big warning when the
+not to force them running around setting configuration variables and
-configuration variable is missing.  Please refer to:
+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.
 
-  http://git.or.cz/gitwiki/GitFaq#non-bare
+For changes decided to be in 1.7.0, we have been much louder to strongly
-  http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
+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.
 
-for more details on the reason why this change is needed and the
-transition plan.
 
 Updates since v1.6.5
 --------------------
@@ -76,6 +134,12 @@ Updates since v1.6.5
  * "git diff" learned --submodule option to show a list of one-line logs
    instead of differences between the commit object names.
 
+ * "git fetch" learned --all and --multiple options, to run fetch from
+   many repositories, and --prune option to remove remote tracking
+   branches that went stale.  These make "git remote update" and "git
+   remote prune" less necessary (there is no plan to remove "remote
+   update" nor "remote prune", though).
+
  * "git fsck" by default checks the packfiles (i.e. "--full" is the
    default); you can turn it off with "git fsck --no-full".
 
@@ -88,6 +152,9 @@ Updates since v1.6.5
 
  * "git log --decorate" shows the location of HEAD as well.
 
+ * "git log" and "git rev-list" learned to take revs and pathspecs from
+   the standard input with the new "--stdin" option.
+
  * "--pretty=format" option to "log" family of commands learned:
 
    . to wrap text with the "%w()" specifier.
@@ -125,5 +192,5 @@ release, unless otherwise noted.
 ---
 exec >/var/tmp/1
 echo O=$(git describe master)
-O=v1.6.5.3-337-gf341feb
+O=v1.6.6-rc0-62-g7fc9d15
 git shortlog --no-merges $O..master --not maint