1 Git v1.6.6 Release Notes
2 ========================
4 Notes on behaviour change
5 -------------------------
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.
15 Preparing yourselves for compatibility issues in 1.7.0
16 ------------------------------------------------------
18 In git 1.7.0, which is planned to be the release after 1.6.6, there will
19 be a handful of behaviour changes that will break backward compatibility.
21 These changes were discussed long time ago and existing behaviours have
22 been identified as more problematic to the userbase than keeping them for
23 the sake of backward compatibility.
25 When necessary, transition strategy for existing users has been designed
26 not to force them running around setting configuration variables and
27 updating their scripts in order to either keep the traditional behaviour
28 or use the new behaviour on the day their sysadmin decides to install
29 the new version of git. When we switched from "git-foo" to "git foo" in
30 1.6.0, even though the change had been advertised and the transition
31 guide had been provided for a very long time, the users procrastinated
32 during the entire transtion period, and ended up panicking on the day
33 their sysadmins updated their git installation. We tried very hard to
34 avoid repeating that unpleasantness.
36 For changes decided to be in 1.7.0, we have been much louder to strongly
37 discourage such procrastination. If you have been using recent versions
38 of git, you would have already seen warnings issued when you exercised
39 features whose behaviour will change, with the instruction on how to
40 keep the existing behaviour if you want to. You hopefully should be
41 well prepared already.
43 Of course, we have also given "this and that will change in 1.7.0;
44 prepare yourselves" warnings in the release notes and announcement
45 messages. Let's see how well users will fare this time.
47 * "git push" into a branch that is currently checked out (i.e. pointed by
48 HEAD in a repository that is not bare) will be refused by default.
50 Similarly, "git push $there :$killed" to delete the branch $killed
51 in a remote repository $there, when $killed branch is the current
52 branch pointed at by its HEAD, will be refused by default.
54 Setting the configuration variables receive.denyCurrentBranch and
55 receive.denyDeleteCurrent to 'ignore' in the receiving repository
56 can be used to override these safety features. Versions of git
57 since 1.6.2 have issued a loud warning when you tried to do them
58 without setting the configuration, so repositories of people who
59 still need to be able to perform such a push should already have
64 http://git.or.cz/gitwiki/GitFaq#non-bare
65 http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
67 for more details on the reason why this change is needed and the
68 transition process that already took place so far.
70 * "git send-email" will not make deep threads by default when sending a
71 patch series with more than two messages. All messages will be sent
72 as a reply to the first message, i.e. cover letter. Git 1.6.6 (this
73 release) will issue a warning about the upcoming default change, when
74 it uses the traditional "deep threading" behaviour as the built-in
75 default. To squelch the warning but still use the "deep threading"
76 behaviour, give --chain-reply-to option or set sendemail.chainreplyto
79 It has been possible to configure send-email to send "shallow thread"
80 by setting sendemail.chainreplyto configuration variable to false.
81 The only thing 1.7.0 release will do is to change the default when
82 you haven't configured that variable.
84 * "git status" will not be "git commit --dry-run". This change does not
85 affect you if you run the command without pathspec.
87 Nobody sane found the current behaviour of "git status Makefile" useful
88 nor meaningful, and it confused users. "git commit --dry-run" has been
89 provided as a way to get the current behaviour of this command since
92 * "git diff" traditionally treated various "ignore whitespace" options
93 only as a way to filter the patch output. "git diff --exit-code -b"
94 exited with non-zero status even if all changes were about changing the
95 ammount of whitespace and nothing else. and "git diff -b" showed the
96 "diff --git" header line for such a change without patch text.
98 In 1.7.0, the "ignore whitespaces" will affect the semantics of the
99 diff operation itself. A change that does not affect anything but
100 whitespaces will be reported with zero exit status when run with
101 --exit-code, and there will not be "diff --git" header for such a
110 * various git-gui updates including new translations, wm states, etc.
114 * "git fetch" over http learned a new mode that is different from the
115 traditional "dumb commit walker".
119 * imap-send can be built on mingw port.
123 * "git diff -B" has smaller memory footprint.
125 (usability, bells and whistles)
127 * The object replace mechanism can be bypassed with --no-replace-objects
128 global option given to the "git" program.
130 * In configuration files, a few variables that name paths can begin with ~/
131 and ~username/ and they are expanded as expected.
133 * "git subcmd -h" now shows short usage help for many more subcommands.
135 * "git bisect reset" can reset to an arbitrary commit.
137 * "git checkout frotz" when there is no local branch "frotz" but there
138 is only one remote tracking branch "frotz" is taken as a request to
139 start the named branch at the corresponding remote tracking branch.
141 * "git commit -c/-C/--amend" can be told with a new "--reset-author" option
142 to ignore authorship information in the commit it is taking the message
145 * "git describe" can be told to add "-dirty" suffix with "--dirty" option.
147 * "git diff" learned --submodule option to show a list of one-line logs
148 instead of differences between the commit object names.
150 * "git diff" learned to honor diff.color.func configuration to paint
151 function name hint printed on the hunk header "@@ -j,k +l,m @@" line
152 in the specified color.
154 * "git fetch" learned --all and --multiple options, to run fetch from
155 many repositories, and --prune option to remove remote tracking
156 branches that went stale. These make "git remote update" and "git
157 remote prune" less necessary (there is no plan to remove "remote
158 update" nor "remote prune", though).
160 * "git fsck" by default checks the packfiles (i.e. "--full" is the
161 default); you can turn it off with "git fsck --no-full".
163 * "git grep" can use -F (fixed strings) and -i (ignore case) together.
165 * import-tars contributed fast-import frontend learned more types of
168 * "git instaweb" knows how to talk with mod_cgid to apache2.
170 * "git log --decorate" shows the location of HEAD as well.
172 * "git log" and "git rev-list" learned to take revs and pathspecs from
173 the standard input with the new "--stdin" option.
175 * "--pretty=format" option to "log" family of commands learned:
177 . to wrap text with the "%w()" specifier.
178 . to show reflog information with "%g[sdD]" specifier.
180 * "git notes" command to annotate existing commits.
182 * "git merge" (and "git pull") learned --ff-only option to make it fail
183 if the merge does not result in a fast-forward.
185 * The ancient "git merge <message> HEAD <branch>..." syntax will be
186 removed in later versions of git. A warning is given and tells
187 users to use the "git merge -m <message> <branch>..." instead.
189 * "git mergetool" learned to use p4merge.
191 * "git rebase -i" learned "reword" that acts like "edit" but immediately
192 starts an editor to tweak the log message without returning control to
193 the shell, which is done by "edit" to give an opportunity to tweak the
196 * "git send-email" can be told with "--envelope-sender=auto" to use the
197 same address as "From:" address as the envelope sender address.
199 * "git send-email" will issue a warning when it defaults to the
200 --chain-reply-to behaviour without being told by the user and
201 instructs to prepare for the change of the default in 1.7.0 release.
203 * In "git submodule add <repository> <path>", <path> is now optional and
204 inferred from <repository> the same way "git clone <repository>" does.
206 * "git svn" learned to read SVN 1.5+ and SVK merge tickets.
208 * "gitweb" can optionally render its "blame" output incrementally (this
209 requires JavaScript on the client side).
211 * Author names shown in gitweb output are links to search commits by the
220 All of the fixes in v1.6.5.X maintenance series are included in this
221 release, unless otherwise noted.
223 * Enumeration of available merge strategies iterated over the list of
224 commands in a wrong way, sometimes producing an incorrect result.
225 Will backport by merging ed87465 (builtin-merge.c: call
226 exclude_cmds() correctly., 2009-11-25).
228 * "git format-patch revisions... -- path" issued an incorrect error
229 message that suggested to use "--" on the command line when path
230 does not exist in the current work tree (it is a separate matter if
231 it makes sense to limit format-patch with pathspecs like that
232 without using the --full-diff option). Will backport by merging
233 7e93d3b (format-patch: add test for parsing of "--", 2009-11-26).
235 * "git shortlog" did not honor the "encoding" header embedded in the
236 commit object like "git log" did. Will backport by merging 79f7ca0
237 (shortlog: respect commit encoding, 2009-11-25).
241 echo O=$(git describe master)
242 O=v1.6.6-rc0-119-gc0ecb07
243 git shortlog --no-merges $O..master --not maint