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 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
-their sysadmins updated their git installation. We tried very hard to
-avoid repeating that unpleasantness.
-
-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.
-
-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.
+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 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:
(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 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 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-rc0-96-gb5d4cf2
-git shortlog --no-merges $O..master --not maint