| 1 | Git v1.9.0 Release Notes |
| 2 | ======================== |
| 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 |
| 10 | get their argument split at $IFS whitespaces by the shell, and got |
| 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 |
| 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. |
| 17 | |
| 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 |
| 20 | command line without the option. |
| 21 | |
| 22 | The way "git push $there $what" interprets the $what part given on the |
| 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 | |
| 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 | |
| 29 | |
| 30 | Backward compatibility notes (for Git 2.0.0) |
| 31 | -------------------------------------------- |
| 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 | |
| 82 | * The HTTP transport, when talking GSS-Negotiate, uses "100 |
| 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 | |
| 88 | * The build procedure is aware of MirBSD now. |
| 89 | |
| 90 | * Various "git p4", "git svn" and "gitk" updates. |
| 91 | |
| 92 | |
| 93 | UI, Workflows & Features |
| 94 | |
| 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 |
| 99 | more controlled way (i.e. the receiver becomes a shallow repository |
| 100 | with a truncated history). |
| 101 | |
| 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 | |
| 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 | |
| 110 | * Fetching a 'frotz' branch with "git fetch", while a 'frotz/nitfol' |
| 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" |
| 114 | now can be used to remove 'frotz/nitfol' to make room for fetching and |
| 115 | storing the 'frotz' remote-tracking branch. |
| 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 | |
| 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 | |
| 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 | |
| 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 | |
| 167 | |
| 168 | Performance, Internal Implementation, etc. |
| 169 | |
| 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 | |
| 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 |
| 180 | result is represented--packing the same set of objects using |
| 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 | |
| 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 | |
| 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 |
| 200 | work has been based on. "git rebase" has the same logic that can be |
| 201 | triggered with the "--fork-point" option. |
| 202 | |
| 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. |
| 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 | |
| 220 | * The pathspec matching code, while comparing two trees (e.g. "git |
| 221 | diff A B -- path1 path2") was too aggressive and failed to match |
| 222 | some paths when multiple pathspecs were involved. |
| 223 | |
| 224 | * "git repack --max-pack-size=8g" stopped being parsed correctly when |
| 225 | the command was reimplemented in C. |
| 226 | |
| 227 | * An earlier update in v1.8.4.x to "git rev-list --objects" with |
| 228 | negative ref had a performance regression. |
| 229 | (merge 200abe7 jk/mark-edges-uninteresting later to maint). |
| 230 | |
| 231 | * A recent update to "git send-email" broke platforms where |
| 232 | /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path |
| 233 | (e.g. Fedora rawhide). |
| 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. |
| 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. |
| 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. |
| 247 | |
| 248 | * documentations to "git pull" hinted there is an "-m" option because |
| 249 | it incorrectly shared the documentation with "git merge". |
| 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 | |
| 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 | |
| 262 | * The implementation of 'git stash $cmd "stash@{...}"' did not quote |
| 263 | the stash argument properly and left it split at IFS whitespace. |
| 264 | |
| 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. |
| 268 | |
| 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 |
| 271 | there was. |
| 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. |
| 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. |
| 282 | |
| 283 | * An earlier "clean-up" introduced an unnecessary memory leak. |
| 284 | |
| 285 | * "git add -A" (no other arguments) in a totally empty working tree |
| 286 | used to emit an error. |
| 287 | |
| 288 | * "git log --decorate" did not handle a tag pointed by another tag |
| 289 | nicely. |
| 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 |
| 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 |
| 296 | fall back to a reasonable low value rather than dying. |
| 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. |
| 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. |
| 311 | |
| 312 | * "git mv A B/", when B does not exist as a directory, should error |
| 313 | out, but it didn't. |
| 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". |
| 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. |
| 326 | |
| 327 | * "git fetch --depth=0" was a no-op, and was silently ignored. |
| 328 | Diagnose it as an error. |
| 329 | |
| 330 | * Remote repository URLs expressed in scp-style host:path notation are |
| 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. |
| 333 | |
| 334 | * "git diff -- ':(icase)makefile'" was unnecessarily rejected at the |
| 335 | command line parser. |
| 336 | |
| 337 | * "git cat-file --batch-check=ok" did not check the existence of |
| 338 | the named object. |
| 339 | |
| 340 | * "git am --abort" sometimes complained about not being able to write |
| 341 | a tree with an 0{40} object in it. |
| 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. |