2 files changed, 137 insertions, 21 deletions
diff --git a/Documentation/RelNotes/1.8.2.txt b/Documentation/RelNotes/1.8.2.txt
index 861ef026d6..fc606ae116 100644
--- a/Documentation/RelNotes/1.8.2.txt
+++ b/Documentation/RelNotes/1.8.2.txt
@@ -1,19 +1,8 @@
 Git v1.8.2 Release Notes
 ========================
 
-Backward compatibility notes
-----------------------------
-
-In the next major release Git 2.0 (not *this* one), we will change the
-behavior of the "git push" command.
-
-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).  We will use 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.
+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
@@ -22,17 +11,41 @@ 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
+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 warning in such a case and
-encourage the user to say "git add -u/-A ." instead when restricting
-the scope to the current directory. At Git 2.0 (not *this* one), we
-plan to change these commands without pathspec to operate on the
-entire tree, and training your fingers to type "." will protect you
-against the future change.
+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
@@ -463,3 +476,20 @@ details).
 
  * Scripts to test bash completion was inherently flaky as it was
    affected by whatever random things the user may have on $PATH.
+
+ * An element on GIT_CEILING_DIRECTORIES could be a "logical" pathname
+   that uses a symbolic link to point at somewhere else (e.g. /home/me
+   that points at /net/host/export/home/me, and the latter directory
+   is automounted). Earlier when Git saw such a pathname e.g. /home/me
+   on this environment variable, the "ceiling" mechanism did not take
+   effect. With this release (the fix has also been merged to the
+   v1.8.1.x maintenance series), elements on GIT_CEILING_DIRECTORIES
+   are by default checked for such aliasing coming from symbolic
+   links. As this needs to actually resolve symbolic links for each
+   element on the GIT_CEILING_DIRECTORIES, you can disable this
+   mechanism for some elements by listing them after an empty element
+   on the GIT_CEILING_DIRECTORIES. e.g. Setting /home/me::/home/him to
+   GIT_CEILING_DIRECTORIES makes Git resolve symbolic links in
+   /home/me when checking if the current directory is under /home/me,
+   but does not do so for /home/him.
+   (merge 7ec30aa mh/maint-ceil-absolute later to maint).
diff --git a/Documentation/RelNotes/1.8.3.txt b/Documentation/RelNotes/1.8.3.txt
new file mode 100644
index 0000000000..a71d660106
--- /dev/null
+++ b/Documentation/RelNotes/1.8.3.txt
@@ -0,0 +1,86 @@
+Git v1.8.3 Release Notes
+========================
+
+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.2
+--------------------
+
+UI, Workflows & Features
+
+
+
+Foreign Interface
+
+
+
+Performance, Internal Implementation, etc.
+
+ * Updates for building under msvc.
+
+
+Also contains minor documentation updates and code clean-ups.
+
+
+Fixes since v1.8.2
+------------------
+
+Unless otherwise noted, all the fixes since v1.8.2 in the maintenance
+track are contained in this release (see release notes to them for
+details).
+
+ * The "--color=<when>" argument to the commands in the diff family
+   was described poorly.
+   (merge 3d0e75f jc/color-diff-doc later to maint).
+
+ * The arguments given to pre-rebase hook were not documented.
+   (merge 0414acc wk/doc-pre-rebase later to maint).
+
+ * The v4 index format was not documented.
+   (merge 647d879 nd/doc-index-format later to maint).
+
+ * The "--match=<pattern>" argument "git describe" takes uses glob
+   pattern but it wasn't obvious from the documentation.
+   (merge 5229149 gp/describe-match-uses-glob-pattern later to maint).
+
+ * Some sources failed to compile on systems that lack NI_MAXHOST in
+   their system header (e.g. z/OS).
+   (merge 3b130ade dm/ni-maxhost-may-be-missing later to maint).
+
+ * Add an example use of "--env-filter" in "filter-branch"
+   documentation.
+   (merge 21b6e4f tk/doc-filter-branch later to maint).
+
+ * "git bundle verify" did not say "records a complete history" for a
+   bundle that does not have any prerequisites.
+   (merge a02ffe0 lf/bundle-verify-list-prereqs later to maint).
+
+ * In the v1.8.0 era, we changed symbols that do not have to be global
+   to file scope static, but a few functions in graph.c were used by
+   CGit from sideways bypassing the entry points of the API the
+   in-tree users use.
+   (merge ac751a0 jk/graph-c-expose-symbols-for-cgit later to maint).