1Git v1.8.5 Release Notes 2======================== 3 4Backward compatibility notes (for Git 2.0) 5------------------------------------------ 6 7When "git push [$there]" does not say what to push, we have used the 8traditional "matching" semantics so far (all your branches were sent 9to the remote as long as there already are branches of the same name 10over there). In Git 2.0, the default will change to the "simple" 11semantics that pushes: 12 13 - only the current branch to the branch with the same name, and only 14 when the current branch is set to integrate with that remote 15 branch, if you are pushing to the same remote as you fetch from; or 16 17 - only the current branch to the branch with the same name, if you 18 are pushing to a remote that is not where you usually fetch from. 19 20Use the user preference configuration variable "push.default" to 21change this. If you are an old-timer who is used to the "matching" 22semantics, you can set the variable to "matching" to keep the 23traditional behaviour. If you want to live in the future early, you 24can set it to "simple" today without waiting for Git 2.0. 25 26When "git add -u" (and "git add -A") is run inside a subdirectory and 27does not specify which paths to add on the command line, it 28will operate on the entire tree in Git 2.0 for consistency 29with "git commit -a" and other commands. There will be no 30mechanism to make plain "git add -u" behave like "git add -u .". 31Current users of "git add -u" (without a pathspec) should start 32training their fingers to explicitly say "git add -u ." 33before Git 2.0 comes. A warning is issued when these commands are 34run without a pathspec and when you have local changes outside the 35current directory, because the behaviour in Git 2.0 will be different 36from today's version in such a situation. 37 38In Git 2.0, "git add <path>" will behave as "git add -A <path>", so 39that "git add dir/" will notice paths you removed from the directory 40and record the removal. Versions before Git 2.0, including this 41release, will keep ignoring removals, but the users who rely on this 42behaviour are encouraged to start using "git add --ignore-removal <path>" 43now before 2.0 is released. 44 45 46Updates since v1.8.4 47-------------------- 48 49Foreign interfaces, subsystems and ports. 50 51 52UI, Workflows & Features 53 54 * "git whatchanged" may still be used by old timers, but mention of 55 it in documents meant for new users will only waste readers' time 56 wonderig what the difference is between it and "git log". Make it 57 less prominent in the general part of the documentation and explain 58 that it is merely a "git log" with different default behaviour in 59 its own document. 60 61 62Performance, Internal Implementation, etc. 63 64 65Also contains various documentation updates and code clean-ups. 66 67 68Fixes since v1.8.4 69------------------ 70 71Unless otherwise noted, all the fixes since v1.8.4 in the maintenance 72track are contained in this release (see release notes to them for 73details). 74 75 * Some people still use rather old versions of bash, which cannot 76 grok some constructs like 'printf -v varname' the prompt and 77 completion code started to use recently. 78 (merge a44aa69 bc/completion-for-bash-3.0 later to maint). 79 80 * Code to read configuration from a blob object did not compile on 81 platforms with fgetc() etc. implemented as macros. 82 (merge 49d6cfa hv/config-from-blob later to maint-1.8.3). 83 84 * The recent "short-cut clone connectivity check" topic broke a 85 shallow repository when a fetch operation tries to auto-follow tags. 86 (merge 6da8bdc nd/fetch-pack-shallow-fix later to maint-1.8.3).