1Git v1.6.6 Release Notes 2======================== 3 4Notes on behaviour change 5------------------------- 6 7 * In this release, "git fsck" defaults to "git fsck --full" and 8 checks packfiles, and because of this it will take much longer to 9 complete than before. If you prefer a quicker check only on loose 10 objects (the old default), you can say "git fsck --no-full". This 11 has been supported by 1.5.4 and newer versions of git, so it is 12 safe to write it in your script even if you use slightly older git 13 on some of your machines. 14 15Preparing yourselves for compatibility issues in 1.7.0 16------------------------------------------------------ 17 18In git 1.7.0, which is planned to be the release after 1.6.6, there will 19be a handful of behaviour changes that will break backward compatibility. 20 21These changes were discussed long time ago and existing behaviours have 22been identified as more problematic to the userbase than keeping them for 23the sake of backward compatibility. 24 25When necessary, transition strategy for existing users has been designed 26not to force them running around setting configuration variables and 27updating their scripts in order to either keep the traditional behaviour 28or adjust to the new behaviour on the day their sysadmin decides to install 29the new version of git. When we switched from "git-foo" to "git foo" in 301.6.0, even though the change had been advertised and the transition 31guide had been provided for a very long time, the users procrastinated 32during the entire transtion period, and ended up panicking on the day 33their sysadmins updated their git installation. We are trying to avoid 34repeating that unpleasantness in the 1.7.0 release. 35 36For changes decided to be in 1.7.0, commands that will be affected 37have been much louder to strongly discourage such procrastination. If 38you have been using recent versions of git, you would have seen 39warnings issued when you exercised features whose behaviour will 40change, with a clear instruction on how to keep the existing behaviour 41if you want to. You hopefully are already well prepared. 42 43Of course, we have also been giving "this and that will change in 441.7.0; prepare yourselves" warnings in the release notes and 45announcement messages for the past few releases. Let's see how well 46users will fare this time. 47 48 * "git push" into a branch that is currently checked out (i.e. pointed by 49 HEAD in a repository that is not bare) will be refused by default. 50 51 Similarly, "git push $there :$killed" to delete the branch $killed 52 in a remote repository $there, when $killed branch is the current 53 branch pointed at by its HEAD, will be refused by default. 54 55 Setting the configuration variables receive.denyCurrentBranch and 56 receive.denyDeleteCurrent to 'ignore' in the receiving repository 57 can be used to override these safety features. Versions of git 58 since 1.6.2 have issued a loud warning when you tried to do these 59 operations without setting the configuration, so repositories of 60 people who still need to be able to perform such a push should 61 already have been future proofed. 62 63 Please refer to: 64 65 http://git.or.cz/gitwiki/GitFaq#non-bare 66 http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 67 68 for more details on the reason why this change is needed and the 69 transition process that already took place so far. 70 71 * "git send-email" will not make deep threads by default when sending a 72 patch series with more than two messages. All messages will be sent 73 as a reply to the first message, i.e. cover letter. Git 1.6.6 (this 74 release) will issue a warning about the upcoming default change, when 75 it uses the traditional "deep threading" behaviour as the built-in 76 default. To squelch the warning but still use the "deep threading" 77 behaviour, give --chain-reply-to option or set sendemail.chainreplyto 78 to true. 79 80 It has been possible to configure send-email to send "shallow thread" 81 by setting sendemail.chainreplyto configuration variable to false. 82 The only thing 1.7.0 release will do is to change the default when 83 you haven't configured that variable. 84 85 * "git status" will not be "git commit --dry-run". This change does not 86 affect you if you run the command without pathspec. 87 88 Nobody sane found the current behaviour of "git status Makefile" useful 89 nor meaningful, and it confused users. "git commit --dry-run" has been 90 provided as a way to get the current behaviour of this command since 91 1.6.5. 92 93 * "git diff" traditionally treated various "ignore whitespace" options 94 only as a way to filter the patch output. "git diff --exit-code -b" 95 exited with non-zero status even if all changes were about changing the 96 ammount of whitespace and nothing else. and "git diff -b" showed the 97 "diff --git" header line for such a change without patch text. 98 99 In 1.7.0, the "ignore whitespaces" will affect the semantics of the 100 diff operation itself. A change that does not affect anything but 101 whitespaces will be reported with zero exit status when run with 102 --exit-code, and there will not be "diff --git" header for such a 103 change. 104 105 106Updates since v1.6.5 107-------------------- 108 109(subsystems) 110 111 * various gitk updates including use of themed widgets under Tk 8.5, 112 Japanese translation, a fix to a bug when running "gui blame" from 113 a subdirectory, etc. 114 115 * various git-gui updates including new translations, wm states fixes, 116 Tk bug workaround after quitting, improved heuristics to trigger gc, 117 etc. 118 119 * various git-svn updates. 120 121 * "git fetch" over http learned a new mode that is different from the 122 traditional "dumb commit walker". 123 124(portability) 125 126 * imap-send can be built on mingw port. 127 128(performance) 129 130 * "git diff -B" has smaller memory footprint. 131 132(usability, bells and whistles) 133 134 * The object replace mechanism can be bypassed with --no-replace-objects 135 global option given to the "git" program. 136 137 * In configuration files, a few variables that name paths can begin with ~/ 138 and ~username/ and they are expanded as expected. 139 140 * "git subcmd -h" now shows short usage help for many more subcommands. 141 142 * "git bisect reset" can reset to an arbitrary commit. 143 144 * "git checkout frotz" when there is no local branch "frotz" but there 145 is only one remote tracking branch "frotz" is taken as a request to 146 start the named branch at the corresponding remote tracking branch. 147 148 * "git commit -c/-C/--amend" can be told with a new "--reset-author" option 149 to ignore authorship information in the commit it is taking the message 150 from. 151 152 * "git describe" can be told to add "-dirty" suffix with "--dirty" option. 153 154 * "git diff" learned --submodule option to show a list of one-line logs 155 instead of differences between the commit object names. 156 157 * "git diff" learned to honor diff.color.func configuration to paint 158 function name hint printed on the hunk header "@@ -j,k +l,m @@" line 159 in the specified color. 160 161 * "git fetch" learned --all and --multiple options, to run fetch from 162 many repositories, and --prune option to remove remote tracking 163 branches that went stale. These make "git remote update" and "git 164 remote prune" less necessary (there is no plan to remove "remote 165 update" nor "remote prune", though). 166 167 * "git fsck" by default checks the packfiles (i.e. "--full" is the 168 default); you can turn it off with "git fsck --no-full". 169 170 * "git grep" can use -F (fixed strings) and -i (ignore case) together. 171 172 * import-tars contributed fast-import frontend learned more types of 173 compressed tarballs. 174 175 * "git instaweb" knows how to talk with mod_cgid to apache2. 176 177 * "git log --decorate" shows the location of HEAD as well. 178 179 * "git log" and "git rev-list" learned to take revs and pathspecs from 180 the standard input with the new "--stdin" option. 181 182 * "--pretty=format" option to "log" family of commands learned: 183 184 . to wrap text with the "%w()" specifier. 185 . to show reflog information with "%g[sdD]" specifier. 186 187 * "git notes" command to annotate existing commits. 188 189 * "git merge" (and "git pull") learned --ff-only option to make it fail 190 if the merge does not result in a fast-forward. 191 192 * "git mergetool" learned to use p4merge. 193 194 * "git rebase -i" learned "reword" that acts like "edit" but immediately 195 starts an editor to tweak the log message without returning control to 196 the shell, which is done by "edit" to give an opportunity to tweak the 197 contents. 198 199 * "git send-email" can be told with "--envelope-sender=auto" to use the 200 same address as "From:" address as the envelope sender address. 201 202 * "git send-email" will issue a warning when it defaults to the 203 --chain-reply-to behaviour without being told by the user and 204 instructs to prepare for the change of the default in 1.7.0 release. 205 206 * In "git submodule add <repository> <path>", <path> is now optional and 207 inferred from <repository> the same way "git clone <repository>" does. 208 209 * "git svn" learned to read SVN 1.5+ and SVK merge tickets. 210 211 * "gitweb" can optionally render its "blame" output incrementally (this 212 requires JavaScript on the client side). 213 214 * Author names shown in gitweb output are links to search commits by the 215 author. 216 217 218(developers) 219 220Fixes since v1.6.5 221------------------ 222 223All of the fixes in v1.6.5.X maintenance series are included in this 224release, unless otherwise noted. 225 226--- 227exec >/var/tmp/1 228echo O=$(git describe master) 229O=v1.6.6-rc1-79-g529f8c6 230git shortlog --no-merges $O..master --not maint