From 66abce05dd5b9da9c889034781dc3de38b6e231b Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Sat, 28 Nov 2009 11:13:59 -0800 Subject: [PATCH] Update draft release notes to 1.6.6 before merging topics for -rc1 Signed-off-by: Junio C Hamano --- Documentation/RelNotes-1.6.6.txt | 133 +++++++++++++++++++++++++++++---------- 1 file changed, 100 insertions(+), 33 deletions(-) diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt index 371101d667..6163b4aad3 100644 --- a/Documentation/RelNotes-1.6.6.txt +++ b/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 -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. +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. -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 -------------------- @@ -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 -- 2.11.4.GIT