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
--------------------
* "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".
* "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.
---
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