]>
Commit | Line | Data |
---|---|---|
5f95c9f8 JH |
1 | Git v1.9.0 Release Notes |
2 | ======================== | |
077f4344 JH |
3 | |
4 | Backward compatibility notes | |
5 | ---------------------------- | |
6 | ||
7 | "git submodule foreach $cmd $args" used to treat "$cmd $args" the same | |
8 | way "ssh" did, concatenating them into a single string and letting the | |
9 | shell unquote. Careless users who forget to sufficiently quote $args | |
9c8ce739 | 10 | get their argument split at $IFS whitespaces by the shell, and got |
077f4344 JH |
11 | unexpected results due to this. Starting from this release, the |
12 | command line is passed directly to the shell, if it has an argument. | |
13 | ||
14 | Read-only support for experimental loose-object format, in which users | |
9c8ce739 MG |
15 | could optionally choose to write their loose objects for a short |
16 | while between v1.4.3 and v1.5.3 era, has been dropped. | |
077f4344 | 17 | |
9c8ce739 MG |
18 | The meanings of the "--tags" option to "git fetch" has changed; the |
19 | command fetches tags _in addition to_ what is fetched by the same | |
d7aced95 JH |
20 | command line without the option. |
21 | ||
9c8ce739 | 22 | The way "git push $there $what" interprets the $what part given on the |
a25014bc JH |
23 | command line, when it does not have a colon that explicitly tells us |
24 | what ref at the $there repository is to be updated, has been enhanced. | |
25 | ||
d7aced95 JH |
26 | A handful of ancient commands that have long been deprecated are |
27 | finally gone (repo-config, tar-tree, lost-found, and peek-remote). | |
28 | ||
077f4344 | 29 | |
5f95c9f8 JH |
30 | Backward compatibility notes (for Git 2.0.0) |
31 | -------------------------------------------- | |
077f4344 JH |
32 | |
33 | When "git push [$there]" does not say what to push, we have used the | |
34 | traditional "matching" semantics so far (all your branches were sent | |
35 | to the remote as long as there already are branches of the same name | |
36 | over there). In Git 2.0, the default will change to the "simple" | |
37 | semantics, which pushes: | |
38 | ||
39 | - only the current branch to the branch with the same name, and only | |
40 | when the current branch is set to integrate with that remote | |
41 | branch, if you are pushing to the same remote as you fetch from; or | |
42 | ||
43 | - only the current branch to the branch with the same name, if you | |
44 | are pushing to a remote that is not where you usually fetch from. | |
45 | ||
46 | Use the user preference configuration variable "push.default" to | |
47 | change this. If you are an old-timer who is used to the "matching" | |
48 | semantics, you can set the variable to "matching" to keep the | |
49 | traditional behaviour. If you want to live in the future early, you | |
50 | can set it to "simple" today without waiting for Git 2.0. | |
51 | ||
52 | When "git add -u" (and "git add -A") is run inside a subdirectory and | |
53 | does not specify which paths to add on the command line, it | |
54 | will operate on the entire tree in Git 2.0 for consistency | |
55 | with "git commit -a" and other commands. There will be no | |
56 | mechanism to make plain "git add -u" behave like "git add -u .". | |
57 | Current users of "git add -u" (without a pathspec) should start | |
58 | training their fingers to explicitly say "git add -u ." | |
59 | before Git 2.0 comes. A warning is issued when these commands are | |
60 | run without a pathspec and when you have local changes outside the | |
61 | current directory, because the behaviour in Git 2.0 will be different | |
62 | from today's version in such a situation. | |
63 | ||
64 | In Git 2.0, "git add <path>" will behave as "git add -A <path>", so | |
65 | that "git add dir/" will notice paths you removed from the directory | |
66 | and record the removal. Versions before Git 2.0, including this | |
67 | release, will keep ignoring removals, but the users who rely on this | |
68 | behaviour are encouraged to start using "git add --ignore-removal <path>" | |
69 | now before 2.0 is released. | |
70 | ||
71 | The default prefix for "git svn" will change in Git 2.0. For a long | |
72 | time, "git svn" created its remote-tracking branches directly under | |
73 | refs/remotes, but it will place them under refs/remotes/origin/ unless | |
74 | it is told otherwise with its --prefix option. | |
75 | ||
76 | ||
77 | Updates since v1.8.5 | |
78 | -------------------- | |
79 | ||
80 | Foreign interfaces, subsystems and ports. | |
81 | ||
d7aced95 | 82 | * The HTTP transport, when talking GSS-Negotiate, uses "100 |
077f4344 JH |
83 | Continue" response to avoid having to rewind and resend a large |
84 | payload, which may not be always doable. | |
85 | ||
86 | * Various bugfixes to remote-bzr and remote-hg (in contrib/). | |
87 | ||
a25014bc JH |
88 | * The build procedure is aware of MirBSD now. |
89 | ||
bd3e186d JH |
90 | * Various "git p4", "git svn" and "gitk" updates. |
91 | ||
077f4344 JH |
92 | |
93 | UI, Workflows & Features | |
94 | ||
79fcbf7e JH |
95 | * Fetching from a shallowly-cloned repository used to be forbidden, |
96 | primarily because the codepaths involved were not carefully vetted | |
97 | and we did not bother supporting such usage. This release attempts | |
98 | to allow object transfer out of a shallowly-cloned repository in a | |
9c8ce739 | 99 | more controlled way (i.e. the receiver becomes a shallow repository |
79fcbf7e JH |
100 | with a truncated history). |
101 | ||
864085aa JH |
102 | * Just like we give a reasonable default for "less" via the LESS |
103 | environment variable, we now specify a reasonable default for "lv" | |
104 | via the "LV" environment variable when spawning the pager. | |
105 | ||
a25014bc JH |
106 | * Two-level configuration variable names in "branch.*" and "remote.*" |
107 | hierarchies, whose variables are predominantly three-level, were | |
108 | not completed by hitting a <TAB> in bash and zsh completions. | |
109 | ||
9c8ce739 | 110 | * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol' |
a25014bc JH |
111 | remote-tracking branch from an earlier fetch was still there, would |
112 | error out, primarily because the command was not told that it is | |
113 | allowed to lose any information on our side. "git fetch --prune" | |
9c8ce739 MG |
114 | now can be used to remove 'frotz/nitfol' to make room for fetching and |
115 | storing the 'frotz' remote-tracking branch. | |
a25014bc JH |
116 | |
117 | * "diff.orderfile=<file>" configuration variable can be used to | |
118 | pretend as if the "-O<file>" option were given from the command | |
119 | line of "git diff", etc. | |
120 | ||
121 | * The negative pathspec syntax allows "git log -- . ':!dir'" to tell | |
122 | us "I am interested in everything but 'dir' directory". | |
123 | ||
124 | * "git difftool" shows how many different paths there are in total, | |
125 | and how many of them have been shown so far, to indicate progress. | |
126 | ||
127 | * "git push origin master" used to push our 'master' branch to update | |
128 | the 'master' branch at the 'origin' repository. This has been | |
129 | enhanced to use the same ref mapping "git push origin" would use to | |
130 | determine what ref at the 'origin' to be updated with our 'master'. | |
131 | For example, with this configuration | |
132 | ||
133 | [remote "origin"] | |
134 | push = refs/heads/*:refs/review/* | |
135 | ||
136 | that would cause "git push origin" to push out our local branches | |
137 | to corresponding refs under refs/review/ hierarchy at 'origin', | |
138 | "git push origin master" would update 'refs/review/master' over | |
139 | there. Alternatively, if push.default is set to 'upstream' and our | |
140 | 'master' is set to integrate with 'topic' from the 'origin' branch, | |
141 | running "git push origin" while on our 'master' would update their | |
142 | 'topic' branch, and running "git push origin master" while on any | |
143 | of our branches does the same. | |
144 | ||
b10cd577 JH |
145 | * "gitweb" learned to treat ref hierarchies other than refs/heads as |
146 | if they are additional branch namespaces (e.g. refs/changes/ in | |
147 | Gerrit). | |
148 | ||
077f4344 JH |
149 | * "git for-each-ref --format=..." learned a few formatting directives; |
150 | e.g. "%(color:red)%(HEAD)%(color:reset) %(refname:short) %(subject)". | |
151 | ||
152 | * The command string given to "git submodule foreach" is passed | |
153 | directly to the shell, without being eval'ed. This is a backward | |
154 | incompatible change that may break existing users. | |
155 | ||
156 | * "git log" and friends learned the "--exclude=<glob>" option, to | |
157 | allow people to say "list history of all branches except those that | |
158 | match this pattern" with "git log --exclude='*/*' --branches". | |
159 | ||
160 | * "git rev-parse --parseopt" learned a new "--stuck-long" option to | |
161 | help scripts parse options with an optional parameter. | |
162 | ||
d7aced95 JH |
163 | * The "--tags" option to "git fetch" no longer tells the command to |
164 | fetch _only_ the tags. It instead fetches tags _in addition to_ | |
165 | what are fetched by the same command line without the option. | |
166 | ||
077f4344 JH |
167 | |
168 | Performance, Internal Implementation, etc. | |
169 | ||
864085aa JH |
170 | * When parsing a 40-hex string into the object name, the string is |
171 | checked to see if it can be interpreted as a ref so that a warning | |
172 | can be given for ambiguity. The code kicked in even when the | |
173 | core.warnambiguousrefs is set to false to squelch this warning, in | |
174 | which case the cycles spent to look at the ref namespace were an | |
175 | expensive no-op, as the result was discarded without being used. | |
176 | ||
a25014bc JH |
177 | * The naming convention of the packfiles has been updated; it used to |
178 | be based on the enumeration of names of the objects that are | |
179 | contained in the pack, but now it also depends on how the packed | |
3b19dba7 | 180 | result is represented--packing the same set of objects using |
a25014bc JH |
181 | different settings (or delta order) would produce a pack with |
182 | different name. | |
183 | ||
184 | * "git diff --no-index" mode used to unnecessarily attempt to read | |
185 | the index when there is one. | |
186 | ||
b10cd577 JH |
187 | * The deprecated parse-options macro OPT_BOOLEAN has been removed; |
188 | use OPT_BOOL or OPT_COUNTUP in new code. | |
189 | ||
190 | * A few duplicate implementations of prefix/suffix string comparison | |
191 | functions have been unified to starts_with() and ends_with(). | |
192 | ||
077f4344 JH |
193 | * The new PERLLIB_EXTRA makefile variable can be used to specify |
194 | additional directories Perl modules (e.g. the ones necessary to run | |
195 | git-svn) are installed on the platform when building. | |
196 | ||
197 | * "git merge-base" learned the "--fork-point" mode, that implements | |
198 | the same logic used in "git pull --rebase" to find a suitable fork | |
199 | point out of the reflog entries for the remote-tracking branch the | |
a25014bc JH |
200 | work has been based on. "git rebase" has the same logic that can be |
201 | triggered with the "--fork-point" option. | |
077f4344 | 202 | |
d7aced95 JH |
203 | * A third-party "receive-pack" (the responder to "git push") can |
204 | advertise the "no-thin" capability to tell "git push" not to use | |
205 | the thin-pack optimization. Our receive-pack has always been | |
206 | capable of accepting and fattening a thin-pack, and will continue | |
207 | not to ask "git push" to use a non-thin pack. | |
077f4344 JH |
208 | |
209 | ||
210 | Also contains various documentation updates and code clean-ups. | |
211 | ||
212 | ||
213 | Fixes since v1.8.5 | |
214 | ------------------ | |
215 | ||
216 | Unless otherwise noted, all the fixes since v1.8.5 in the maintenance | |
217 | track are contained in this release (see the maintenance releases' notes | |
218 | for details). | |
219 | ||
bd3e186d | 220 | * The pathspec matching code, while comparing two trees (e.g. "git |
9c8ce739 | 221 | diff A B -- path1 path2") was too aggressive and failed to match |
bd3e186d | 222 | some paths when multiple pathspecs were involved. |
bd3e186d JH |
223 | |
224 | * "git repack --max-pack-size=8g" stopped being parsed correctly when | |
225 | the command was reimplemented in C. | |
bd3e186d JH |
226 | |
227 | * An earlier update in v1.8.4.x to "git rev-list --objects" with | |
9c8ce739 | 228 | negative ref had a performance regression. |
bd3e186d JH |
229 | (merge 200abe7 jk/mark-edges-uninteresting later to maint). |
230 | ||
231 | * A recent update to "git send-email" broke platforms where | |
9c8ce739 | 232 | /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path |
bd3e186d | 233 | (e.g. Fedora rawhide). |
bd3e186d JH |
234 | |
235 | * A handful of bugs around interpreting $branch@{upstream} notation | |
236 | and its lookalike, when $branch part has interesting characters, | |
237 | e.g. "@", and ":", have been fixed. | |
bd3e186d JH |
238 | |
239 | * "git clone" would fail to clone from a repository that has a ref | |
240 | directly under "refs/", e.g. "refs/stash", because different | |
241 | validation paths do different things on such a refname. Loosen the | |
242 | client side's validation to allow such a ref. | |
bd3e186d JH |
243 | |
244 | * "git log --left-right A...B" lost the "leftness" of commits | |
245 | reachable from A when A is a tag as a side effect of a recent | |
246 | bugfix. This is a regression in 1.8.4.x series. | |
bd3e186d JH |
247 | |
248 | * documentations to "git pull" hinted there is an "-m" option because | |
249 | it incorrectly shared the documentation with "git merge". | |
bd3e186d JH |
250 | |
251 | * "git diff A B submod" and "git diff A B submod/" ought to have done | |
252 | the same for a submodule "submod", but didn't. | |
253 | ||
254 | * "git clone $origin foo\bar\baz" on Windows failed to create the | |
255 | leading directories (i.e. a moral-equivalent of "mkdir -p"). | |
256 | ||
79fcbf7e JH |
257 | * "submodule.*.update=checkout", when propagated from .gitmodules to |
258 | .git/config, turned into a "submodule.*.update=none", which did not | |
259 | make much sense. | |
260 | (merge efa8fd7 fp/submodule-checkout-mode later to maint). | |
261 | ||
864085aa JH |
262 | * The implementation of 'git stash $cmd "stash@{...}"' did not quote |
263 | the stash argument properly and left it split at IFS whitespace. | |
864085aa | 264 | |
a25014bc JH |
265 | * The "--[no-]informative-errors" options to "git daemon" were parsed |
266 | a bit too loosely, allowing any other string after these option | |
267 | names. | |
a25014bc | 268 | |
9c8ce739 MG |
269 | * There is no reason to have a hardcoded upper limit for the number of |
270 | parents of an octopus merge, created via the graft mechanism, but | |
a25014bc | 271 | there was. |
a25014bc JH |
272 | |
273 | * The basic test used to leave unnecessary trash directories in the | |
274 | t/ directory. | |
275 | (merge 738a8be jk/test-framework-updates later to maint). | |
276 | ||
277 | * "git merge-base --octopus" used to leave cleaning up suboptimal | |
278 | result to the caller, but now it does the clean-up itself. | |
a25014bc JH |
279 | |
280 | * A "gc" process running as a different user should be able to stop a | |
281 | new "gc" process from starting, but it didn't. | |
a25014bc JH |
282 | |
283 | * An earlier "clean-up" introduced an unnecessary memory leak. | |
a25014bc JH |
284 | |
285 | * "git add -A" (no other arguments) in a totally empty working tree | |
286 | used to emit an error. | |
a25014bc JH |
287 | |
288 | * "git log --decorate" did not handle a tag pointed by another tag | |
289 | nicely. | |
a25014bc JH |
290 | |
291 | * When we figure out how many file descriptors to allocate for | |
292 | keeping packfiles open, a system with non-working getrlimit() could | |
293 | cause us to die(), but because we make this call only to get a | |
9c8ce739 MG |
294 | rough estimate of how many are available and we do not even attempt |
295 | to use up all available file descriptors ourselves, it is nicer to | |
a25014bc | 296 | fall back to a reasonable low value rather than dying. |
a25014bc JH |
297 | |
298 | * read_sha1_file(), that is the workhorse to read the contents given | |
299 | an object name, honoured object replacements, but there was no | |
300 | corresponding mechanism to sha1_object_info() that was used to | |
301 | obtain the metainfo (e.g. type & size) about the object. This led | |
302 | callers to weird inconsistencies. | |
303 | (merge 663a856 cc/replace-object-info later to maint). | |
304 | ||
305 | * "git cat-file --batch=", an admittedly useless command, did not | |
306 | behave very well. | |
a25014bc JH |
307 | |
308 | * "git rev-parse <revs> -- <paths>" did not implement the usual | |
309 | disambiguation rules the commands in the "git log" family used in | |
310 | the same way. | |
a25014bc | 311 | |
b10cd577 JH |
312 | * "git mv A B/", when B does not exist as a directory, should error |
313 | out, but it didn't. | |
b10cd577 JH |
314 | |
315 | * A workaround to an old bug in glibc prior to glibc 2.17 has been | |
316 | retired; this would remove a side effect of the workaround that | |
317 | corrupts system error messages in non-C locales. | |
318 | ||
319 | * SSL-related options were not passed correctly to underlying socket | |
320 | layer in "git send-email". | |
b10cd577 JH |
321 | |
322 | * "git commit -v" appends the patch to the log message before | |
323 | editing, and then removes the patch when the editor returned | |
324 | control. However, the patch was not stripped correctly when the | |
325 | first modified path was a submodule. | |
b10cd577 JH |
326 | |
327 | * "git fetch --depth=0" was a no-op, and was silently ignored. | |
328 | Diagnose it as an error. | |
b10cd577 | 329 | |
9c8ce739 | 330 | * Remote repository URLs expressed in scp-style host:path notation are |
b10cd577 JH |
331 | parsed more carefully (e.g. "foo/bar:baz" is local, "[::1]:/~user" asks |
332 | to connect to user's home directory on host at address ::1. | |
b10cd577 | 333 | |
077f4344 JH |
334 | * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the |
335 | command line parser. | |
077f4344 JH |
336 | |
337 | * "git cat-file --batch-check=ok" did not check the existence of | |
338 | the named object. | |
077f4344 JH |
339 | |
340 | * "git am --abort" sometimes complained about not being able to write | |
341 | a tree with an 0{40} object in it. | |
077f4344 JH |
342 | |
343 | * Two processes creating loose objects at the same time could have | |
344 | failed unnecessarily when the name of their new objects started | |
345 | with the same byte value, due to a race condition. |