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
+When necessary, a 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.
+updating their scripts in order to either keep the traditional behaviour
+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
+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, commands that will be affected
+have been much louder to strongly discourage such procrastination, and
+they continue to be in this release. If you have been using recent
+versions of git, you would have seen warnings issued when you used
+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 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.
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.
+ 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:
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.
+ patch series with more than two messages. All messages will be sent
+ as a reply to the first message, i.e. cover letter. Git 1.6.6 (this
+ release) will issue a warning about the upcoming default change, when
+ it uses the traditional "deep threading" behaviour as the built-in
+ default. To squelch the warning but still use the "deep threading"
+ behaviour, give --chain-reply-to option or set sendemail.chainreplyto
+ to true.
+
+ It has been possible to configure send-email to send "shallow thread"
+ by setting sendemail.chainreplyto configuration variable to false.
+ The only thing 1.7.0 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.
(subsystems)
- * various git-gui updates including new translations, wm states, etc.
+ * various gitk updates including use of themed widgets under Tk 8.5,
+ Japanese translation, a fix to a bug when running "gui blame" from
+ a subdirectory, etc.
- * git-svn updates.
+ * various git-gui updates including new translations, wm states fixes,
+ Tk bug workaround after quitting, improved heuristics to trigger gc,
+ etc.
+
+ * various git-svn updates.
* "git fetch" over http learned a new mode that is different from the
traditional "dumb commit walker".
is only one remote tracking branch "frotz" is taken as a request to
start the named branch at the corresponding remote tracking branch.
+ * "git commit -c/-C/--amend" can be told with a new "--reset-author" option
+ to ignore authorship information in the commit it is taking the message
+ from.
+
* "git describe" can be told to add "-dirty" suffix with "--dirty" option.
* "git diff" learned --submodule option to show a list of one-line logs
instead of differences between the commit object names.
+ * "git diff" learned to honor diff.color.func configuration to paint
+ function name hint printed on the hunk header "@@ -j,k +l,m @@" line
+ in the specified color.
+
* "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
the shell, which is done by "edit" to give an opportunity to tweak the
contents.
+ * "git send-email" can be told with "--envelope-sender=auto" to use the
+ same address as "From:" address as the envelope sender address.
+
+ * "git send-email" will issue a warning when it defaults to the
+ --chain-reply-to behaviour without being told by the user and
+ instructs to prepare for the change of the default in 1.7.0 release.
+
* In "git submodule add <repository> <path>", <path> is now optional and
inferred from <repository> the same way "git clone <repository>" does.
* "git svn" learned to read SVN 1.5+ and SVK merge tickets.
- * Author names shown in gitweb output are links to search commits by the
- author.
+ * "git svn" learned to recreate empty directories tracked only by SVN.
+ * "gitweb" can optionally render its "blame" output incrementally (this
+ requires JavaScript on the client side).
-(developers)
+ * Author names shown in gitweb output are links to search commits by the
+ author.
Fixes since v1.6.5
------------------
All of the fixes in v1.6.5.X maintenance series are included in this
release, unless otherwise noted.
-
----
-exec >/var/tmp/1
-echo O=$(git describe master)
-O=v1.6.6-rc0-62-g7fc9d15
-git shortlog --no-merges $O..master --not maint