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 either keep the traditional behaviour
-or adjust to 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
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. 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.
+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
(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".
* "git svn" learned to read SVN 1.5+ and SVK merge tickets.
+ * "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).
* Author names shown in gitweb output are links to search commits by the
author.
-
-(developers)
-
Fixes since v1.6.5
------------------
All of the fixes in v1.6.5.X maintenance series are included in this
release, unless otherwise noted.
-
- * Enumeration of available merge strategies iterated over the list of
- commands in a wrong way, sometimes producing an incorrect result.
- Will backport by merging ed87465 (builtin-merge.c: call
- exclude_cmds() correctly., 2009-11-25).
-
- * "git format-patch revisions... -- path" issued an incorrect error
- message that suggested to use "--" on the command line when path
- does not exist in the current work tree (it is a separate matter if
- it makes sense to limit format-patch with pathspecs like that
- without using the --full-diff option). Will backport by merging
- 7e93d3b (format-patch: add test for parsing of "--", 2009-11-26).
-
- * "git shortlog" did not honor the "encoding" header embedded in the
- commit object like "git log" did. Will backport by merging 79f7ca0
- (shortlog: respect commit encoding, 2009-11-25).
-
----
-exec >/var/tmp/1
-echo O=$(git describe master)
-O=v1.6.6-rc1-52-gff86bdd
-git shortlog --no-merges $O..master --not maint