Git v1.8.2 Release Notes
========================

Backward compatibility notes (this release)
-------------------------------------------

"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3
that already exists in the repository $there, if the rewritten tag
you are pushing points at a commit that is a descendant of a commit
that the old tag v1.2.3 points at.  This was found to be error prone
and starting with this release, any attempt to update an existing
ref under refs/tags/ hierarchy will fail, without "--force".

When "git add -u" and "git add -A" that does not specify what paths
to add on the command line is run from inside a subdirectory, the
scope of the operation has always been limited to the subdirectory.
Many users found this counter-intuitive, given that "git commit -a"
and other commands operate on the entire tree regardless of where you
are.  In this release, these commands give a warning message that
suggests the users to use "git add -u/-A ." when they want to limit
the scope to the current directory; doing so will squelch the message,
while training their fingers.


Backward compatibility notes (for Git 2.0)
------------------------------------------

When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there).  In Git 2.0, the default will change to the "simple"
semantics that pushes the current branch to the branch with the same
name, only when the current branch is set to integrate with that
remote branch.  There is a user preference configuration variable
"push.default" to change this.  If you are an old-timer who is used
to the "matching" semantics, you can set it to "matching" to keep the
traditional behaviour.  If you want to live in the future early,
you can set it to "simple" today without waiting for Git 2.0.

When "git add -u" and "git add -A", that does not specify what paths
to add on the command line is run from inside a subdirectory, these
commands will operate on the entire tree in Git 2.0 for consistency
with "git commit -a" and other commands. Because there will be no
mechanism to make "git add -u" behave as if "git add -u .", it is
important for those who are used to "git add -u" (without pathspec)
updating the index only for paths in the current subdirectory to start
training their fingers to explicitly say "git add -u ." when they mean
it before Git 2.0 comes.


Updates since v1.8.1
--------------------

UI, Workflows & Features

 * Initial ports to QNX and z/OS UNIX System Services have started.

 * Output from the tests is coloured using "green is okay, yellow is
   questionable, red is bad and blue is informative" scheme.

 * Mention of "GIT/Git/git" in the documentation have been updated to
   be more uniform and consistent.  The name of the system and the
   concept it embodies is "Git"; the command the users type is "git".
   All-caps "GIT" was merely a way to imitate "Git" typeset in small
   caps in our ASCII text only documentation and to be avoided.

 * The completion script (in contrib/completion) used to let the
   default completer to suggest pathnames, which gave too many
   irrelevant choices (e.g. "git add" would not want to add an
   unmodified path).  It learnt to use a more git-aware logic to
   enumerate only relevant ones.

 * In bare repositories, "git shortlog" and other commands now read
   mailmap files from the tip of the history, to help running these
   tools in server settings.

 * Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the
   "--format=" option of "git log" and friends can be disabled when
   the output is not sent to a terminal by prefixing them with
   "auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)".

 * Scripts can ask Git that wildcard patterns in pathspecs they give do
   not have any significance, i.e. take them as literal strings.

 * The patterns in .gitignore and