Update draft release notes to 1.6.6 before -rc2

Reword the 1.7.0 warnings, and drop deprecation of "merge <msg> HEAD <commit>..."
syntax.

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

diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
index afcce8ba9a344989dd56022314394f84fa66df1f..dc55480a14251d3bff430733861428faa5ac1090 100644 (file)
--- a/Documentation/RelNotes-1.6.6.txt
+++ b/Documentation/RelNotes-1.6.6.txt
@@ -25,24 +25,25 @@ 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 either keep the traditional behaviour
 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 either keep the traditional behaviour

-or use the new behaviour on the day their sysadmin decides to install
+or adjust to the new 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
 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 installation.  We tried very hard to
-avoid repeating that unpleasantness.
+their sysadmins updated their git installation.  We are trying to avoid
+repeating that unpleasantness in the 1.7.0 release.

 
 

-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 want to.  You hopefully should be
-well prepared already.
+For changes decided to be in 1.7.0, commands that will be affected
+have been much louder to strongly discourage such procrastination.  If
+you have been using recent versions of git, you would have seen
+warnings issued when you exercised features whose behaviour will
+change, with a clear instruction on how to keep the existing behaviour
+if you want to.  You hopefully are already well prepared.

 
 

-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.
+Of course, we have also been giving "this and that will change in
+1.7.0; prepare yourselves" warnings in the release notes and
+announcement messages for the past few releases.  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.
 
  * "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.


@@ -54,10 +55,10 @@ messages.  Let's see how well users will fare this time.
    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
    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 have
-   been future proofed.
+   since 1.6.2 have issued a loud warning when you tried to do these
+   operations without setting the configuration, so repositories of
+   people who still need to be able to perform such a push should
+   already have been future proofed.

 
    Please refer to:
 
 
    Please refer to:
 


@@ -182,10 +183,6 @@ Updates since v1.6.5
  * "git merge" (and "git pull") learned --ff-only option to make it fail
    if the merge does not result in a fast-forward.
 
  * "git merge" (and "git pull") learned --ff-only option to make it fail
    if the merge does not result in a fast-forward.
 

- * The ancient "git merge <message> HEAD <branch>..." syntax will be
-   removed in later versions of git.  A warning is given and tells
-   users to use the "git merge -m <message> <branch>..." instead.
-

  * "git mergetool" learned to use p4merge.
 
  * "git rebase -i" learned "reword" that acts like "edit" but immediately
  * "git mergetool" learned to use p4merge.
 
  * "git rebase -i" learned "reword" that acts like "edit" but immediately


@@ -239,5 +236,5 @@ release, unless otherwise noted.
 ---
 exec >/var/tmp/1
 echo O=$(git describe master)
 ---
 exec >/var/tmp/1
 echo O=$(git describe master)

-O=v1.6.6-rc0-119-gc0ecb07
+O=v1.6.6-rc1-52-gff86bdd

 git shortlog --no-merges $O..master --not maint
 git shortlog --no-merges $O..master --not maint