add release notes, bump version2.1.0

2 files changed, 406 insertions, 10 deletions

diff --git a/Documentation/RelNotes/1.4.0.txt b/Documentation/RelNotes/1.4.0.txt
index 450c3d7..f0f8d9e 100644
--- a/Documentation/RelNotes/1.4.0.txt
+++ b/Documentation/RelNotes/1.4.0.txt
@@ -4,7 +4,7 @@ Magit v1.4.0 Release Notes
 Released 1 April 2015 by Jonas Bernoulli.
 
 This release sits in the middle of a commit marathon that lasted for
-more than 4400 commits.
+more than 4700 commits.
 
 When I became Magit's new maintainer during the summer of 2013 Magit
 was already a big success, but underneath its shiny surface it was
diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt
index cc94d4b..90a4e53 100644
--- a/Documentation/RelNotes/2.1.0.txt
+++ b/Documentation/RelNotes/2.1.0.txt
@@ -2,50 +2,446 @@ It's Magit!  A Git Porcelain inside Emacs
 =========================================
 
 Magit is an interface to the version control system Git, implemented
-as an Emacs package.  For more information see http://magit.vc.
+as an Emacs package.  Magit aspires to be a complete Git porcelain.
+While we cannot (yet) claim that Magit wraps and improves upon each
+and every Git command, it is complete enough to allow even experienced
+Git users to perform almost all of their daily version control tasks
+directly from within Emacs.  While many fine Git clients exist, only
+Magit and Git itself deserve to be called porcelains.
+
+For more information about Magit, see http://magit.vc.
 
 Magit v2.1.0 Release Notes
 ==========================
 
-UNRELEASED
+Released 1 July 2015 by Jonas Bernoulli.
+
+This release marks the end of a commit marathon that lasted for more
+than 4700 commits.  It is the first major release in over two and a
+half years.  The last major release was 1.2.0, which was released
+under old leadership.  Version 1.4.0, which I released earlier this
+year, for the most part consisted of changes that prepared for this
+release (so you might want to read the respective release notes too).
+
+This release comes with many new and exciting features, but the most
+important change is the massive increase in consistency both in the
+user interface and the internal abstractions.
+
+Magit always provided a very intuitive staging interface, which is
+vastly superior to `git add --interactive'.  This release extends this
+to other apply variants.  Starting with this release, other areas have
+also begun to be more than just incremental improvements over what Git
+itself provides.  But this is still limited to certain features which
+have gotten more attention than others (most prominently rebasing).
+
+Interlude
+---------
+
+The code base is finally in a state that allows me to concentrate on
+implementing my vision of what version control could be like.  But
+this will only be possible if, unlike during the last two and a half
+years, I am being paid for my work.
+
+I intend to run a fund-raising campaign, but you can already donate
+now (see http://magit.vc/donations.html).  I am also looking for
+corporate sponsorship and/or employment.  One area where Magit
+actually lags behind other Git clients is integration with Git hosting
+platforms and code review tools.  I hope that these platforms have an
+interest in being supported by the best Git client and are willing to
+pay for it.
+
+I am very interested in a job that would let me work on Magit *and* on
+other projects, which would benefit from the skills I have acquired
+integrating two complex systems and dealing with all the social and
+technical challenges that arise when running a popular project.
 
 Changes since v1.4.0
 --------------------
 
+ * A new manual has been added.  It's much more comprehensive than the
+   old manual and instead of just documenting the various commands and
+   options, it also explains concepts and plumbing functions, and
+   comes with extensive indices for commands, functions, and options.
+
+   Actually three new manuals were added; the packages `magit-popup'
+   and `with-editor' are documented in separate manuals.
+
+   The manuals are written in Org mode and then exported to Texinfo.
+
+ * Performance is much better now.  In most cases this was achieved by
+   delaying work until it is actually needed.  Most importantly diffs
+   are only partially washed until being fully expanded.  Some
+   features come in a fancy and in a fast variant; when that is the
+   case, we now usually default to the fast variant.
+
+ * Many options can now be set on a per-repository basis, and the
+   manual describes how to do so.  (Actually this was always possible
+   but, because it was undocumented, nobody did it.)  It's possible to
+   define "repository classes", e.g. "huge repositories", and then add
+   the respective repositories to that class.  This is very useful in
+   order to turn off certain features only in repositories where they
+   would have a negative impact on performance, without having to do
+   it for each repository individually.
+
+ * Many faces have been simplified.  Most importantly, section heading
+   faces no longer set a background color (except for hunk headings)
+   and instead just use the default background.  Refname faces no
+   longer set the background color or the box property.
+
+ * Many, probably the majority of, functions, variables, and faces
+   have been renamed, which was necessary because there was very
+   little consistency before.
+
+   Most importantly, the names of commands and options now begin with
+   a prefix that includes the name of the respective git sub-command.
+   For example, the names of all commands and options related to
+   diffing now begin with `magit-diff-'.
+
+   Many plumbing functions and variables were also renamed.  In some
+   cases, that also lead to shared prefixes, such as `magit-process-',
+   `magit-mode-', `magit-git-', and `magit-insert-'.  But many
+   plumbing functions and variables continue to use names whose only
+   common part is the `magit-' prefix.
+
+   Future renames will be performed at well defined times and obsolete
+   function/variable definitions will be provided for backward
+   compatibility.  No renames are planned at present.
+
+ * The external libraries `git-commit-mode.el' and `git-rebase-mode.el'
+   are no longer required and have to be uninstalled because they
+   conflict with their successors `git-commit.el' and `git-rebase.el',
+   which are now maintained inside the Magit repository instead of the
+   Git-Modes repository.
+
+   The library `git-commit.el' can be used without Magit, so it is
+   distributed as a separate Elpa package.  However, `git-rebase.el'
+   now depends on several Magit libraries and is therefore distributed
+   as part of the `magit' package.
+
+ * The library `magit-key-mode.el' was removed and replaced with
+   `magit-popup.el'.  The new implementation is much more flexible and
+   easier to use than the old one.  Major new features include setting
+   default arguments directly inside the popup and macros for defining
+   new popups and extending existing popups.
+
+   This new library can also be used by packages that are not related
+   to Magit and is therefore available as a separate Elpa package.
+
+ * The library `with-editor.el' was added.  Its purpose is to use the
+   emacsclient as $GIT_EDITOR when git is started as a subprocess and
+   requires an editor.  This is used while committing and rebasing.
+   This also works over Tramp, where a "sleeping editor" shell script
+   is used to communicate over standard output instead of a socket
+   like the emacsclient does.
+
+   The `1.4.0' release already supported this, but this release splits
+   this feature into a separate library.  And now that it is a separate
+   library, it can also be used by packages that are not related to
+   Magit.  `with-editor.el' is distributed as a separate Elpa package.
+
+ * All libraries are now located in the new `lisp/' subdirectory.
+
+ * The library `magit.el' has been split into many new libraries.
+   The code base is now much better organized.  Together with the
+   description of plumbing commands in the manual, this should make it
+   much easier for contributors to get started.
+
+ * The library `magit-wip.el' has been rewritten from scratch and no
+   longer depends on the external and unmaintained shell script from
+   https://github.com/bartman/git-wip.
+
+ * There are now three different modes that commit to the
+   work-in-progress refs before/after certain events, and in addition
+   to the old working tree wip refs, these modes now also commit to
+   index wip refs.  When these new modes are turned on, Git's
+   protection of committed (but dangling) changes is effectively
+   extended to uncommitted changes (which some exceptions).  These
+   modes are not enabled by default due to performance concerns.
+
+ * The library `magit-blame.el' has been rewritten from scratch.  The
+   new implementation can blame recursively, jump to the next/previous
+   chunk from the same commit, replace headings with separator lines,
+   scroll the revision buffer for the chunk at point (like log buffers),
+   and fine-tune the arguments for `git blame' using a popup.
+
+ * The new library `magit-ediff.el' replaces the old Ediff support.
+   The new implementation comes with a dwim command and a popup, and
+   it relies less on high-level functions provided by VC and Ediff
+   itself, because many of those turned out to be unsuitable.
+
+ * The popular third-party library `dash.el' is now required.  This
+   is the only mandatory external dependency now, except for Git and
+   Emacs themselves, of course.
+
+ * When using Ido inside Magit, users now have to install the
+   third-party library `ido-completing-read+.el'.  This is necessary
+   because the function `ido-completing-read', which is part of the
+   built-in library `ido.el', is not a sufficient drop-in replacement
+   for `completing-read'.
+
+ * The new macro `magit-insert-section' replaces `magit-with-section'.
+   The macros `magit-cmd-insert-section' and `magit-git-insert-section'
+   were removed without a direct replacement.
+
+ * The new functions `magit-insert' and `magit-put-face-property' take
+   care of working around the fact that negative overlay priorities
+   are not supported, i.e., that overlays always take precedence
+   against text properties.  Previously this was done in various
+   places, and not always correctly (e.g., in some cases overlays did
+   not evaporate).
+
+ * The section visibility and movement commands were rewritten from
+   scratch.  All those commands now share the prefix `magit-section-'
+   and edge cases are handled better.  New commands were added that
+   allow cycling the visibility of sections and their children.  From
+   a user perspective Magit's section handling is now quite similar to
+   that of Org mode.
+
+ * The macro `magit-section-action' was removed.  The related macro
+   `magit-section-case' still exists and will continue to do so.  The
+   action variant provided user-customizable hooks, but these hooks
+   were rarely, if ever, used.  Instead of such action hooks, users who
+   wish to extend Magit now have to use type-specific section keymaps.
+
+ * Section highlighting was rewritten from scratch.  The new
+   implementation uses hooks to allow washing certain section types
+   differently than others - without obfuscating the simple cases.
+   Washing diffs is much more complicated than washing all other
+   sections, and that part has been factored out.  The washing of
+   all other section types is now quite simple.
+
+ * The appearance of the region now indicates whether it is valid as a
+   selection.  As far as Magit is concerned, valid selections are hunk
+   internal regions and regions that mark sibling sections of the same
+   type.  When a region does not satisfy one of these, then it is
+   displayed the sames as in other buffers and Magit cannot act on it.
+
+ * The new option `magit-no-confirm' makes it easy to forgo having to
+   confirm potentially dangerous actions.  Many of these actions are
+   only dangerous for users who don't know how to undo them.  When the
+   wip modes are turned on, many more previously fatal actions can be
+   easily undone.  Adding `safe-with-wip' here makes it unnecessary to
+   confirm these actions.
+
+ * The new Refs buffer combines the features of the old Wazzup and
+   Branch Manager buffers into one, more powerful and efficient
+   synthesis.  For each reference, cherries can be shown by expanding
+   the ref section, but unlike in the Wazzup buffer, the cherries are
+   not calculated until the expansion happens, making it vastly more
+   efficient.  Besides local and remote branches, the buffer now also
+   lists tags, and users can add additional sections listing other
+   refs, e.g., stashes.  The format of refs headers is now
+   customizable.
+
+ * File-visiting buffers are now reverted without using code from the
+   built-in `autorevert.el` library.  The function we previously used
+   was intended for internal use only and indeed, changes made there
+   broke Magit in the past.
+
+ * The new option `magit-revert-buffers' controls whether and how
+   buffers visiting tracked files are reverted.  As before, such
+   buffers are reverted by default.  But by default this is now done
+   rather noisily to encourage users to read the doc-string and
+   pick what is right for them.  It's now also possible to revert
+   asynchronously and for the user to be asked every time there are
+   buffers that could be reverted.  This option replaces
+   `magit-auto-revert-mode`.
+
+ * Many new section inserters are available.  Some are variations of
+   default inserters; `magit-insert-unpulled-cherries', for example, is
+   like `magit-insert-unpulled-commits' but prefixes each commit with
+   "+" or "-" to indicate its "cherry state". Other inserters are
+   completely new (e.g., `magit-insert-unpulled-module-commits').
+
+ * The header sections in status buffers can now be customized using
+   the new `magit-status-headers-hook'.  This is an additional section
+   insertion hook; separating it from `magit-status-sections-hook'
+   gives users complete control over what information is displayed in
+   the headers, while still making the first header the parent section
+   of all the other header lines.
+
+ * Many commands that previously could only act on the section at
+   point can now act on all sections selected by a region, which can
+   span sibling sections of the same type.
+
+ * Many commands now more intelligently dwim based on the section at
+   point.
+
+ * Where it makes sense, completion and confirmation have been merged
+   into a single user action.  Many commands that previously allowed
+   carrying out or aborting some action now also allow the user to act
+   on something different from the default choice.  Where one
+   previously had to confirm with `yes RET', one now confirms with just
+   `RET' (to accept the default choice, which previously was the only
+   choice).
+
+ * The distinction between the various "apply variants" has been
+   clearly worked out, and they now all provide the same feature set.
+   The variants are: stage, unstage, discard, reverse, and "regular
+   apply".  In all cases, it is possible to act on a file, a hunk,
+   files, hunks, and part of a hunk.  When acting on the hunk level,
+   all variants are implemented on top of `git apply', thus the name
+   "apply variants".
+
+   Un-/staging has always been one of Magit's most beloved features,
+   and this release takes it to the next level by making the other
+   apply variants just as consistent, powerful, and intuitive to use.
+
+   All apply variants are context aware, meaning that, for example, the
+   stage variant knows that an already staged change cannot be staged.
+   That leads to better error messages.
+
+ * The committing prefix now features additional variants.  It was
+   already possible to quickly create a fixup or squash commit; the
+   new variants do that and then also instantly perform a rebase to
+   actually combine these commits with their intended target commits.
+
+ * Rebase sequences are now initiated from the new rebasing prefix.
+   Several rebasing variants exist, of course including basic
+   "rebase onto something" and interactive rebase.  Other variants
+   automatically detect and combine squash and fixup commits with
+   their intended targets.  Others let the user edit or reword a
+   single commit, without having to go through the steps that are
+   irrelevant in these cases.
+
+ * When a rebase sequence stops at a commit, then the rebasing prefix
+   instead features suffix commands for continuing, editing, or
+   aborting the sequence; or skipping the current commit.
+
+ * When a rebase sequence stops, the status buffer displays a list of
+   the already applied and yet-to-be applied commits.  These commits
+   can be acted on like those in logs.
+
+ * Cherry-picking, reverting, and applying patches using `git am' are
+   treated the same way as rebasing.  A prefix command features
+   several variants to initiate the sequence.  When a sequence is in
+   progress, then the same prefix instead features suffix commands for
+   continuing or aborting the sequence, and the status buffer lists
+   the relevant commits.
+
+ * The magit-specific "rewriting" feature has been removed because it
+   was a hybrid of "rebasing" and "cherry-picking" and vastly
+   inferior to both of them.
+
+ * The merging prefix features several new convenient merge variants.
+
+ * Merges can now be previewed before actually carrying them out.
+
+ * When a merge results in conflicts then the commits being merged are
+   listed in the status buffer, making it easier to review conflicting
+   changes in the context they were created.
+
+ * Its now possible to discard one side of a conflict directly from
+   the hunk containing the conflict, using the regular discard key
+   `k'.  It's also possible to restore a conflict.
+
+ * When using an existing branch as the starting-point of a new
+   branch, it is now automatically configured as the upstream branch.
+
+ * The branching prefix now features suffix commands for un-/setting
+   the upstream branch.  Previously this was coupled with pushing in
+   a truly obscure way.
+
+ * Branch descriptions can now be displayed in the refs or status
+   buffer, and the description can be edited using a suffix command
+   from the branching prefix.
+
+ * The URL of a remote can now be changed from the remoting prefix.
+
+ * A new pulling prefix command was added, which features several new
+   pulling variants.  Previously only one pulling command existed and
+   it had to be controlled using prefix arguments, which was very
+   cumbersome.
+
+ * A new pushing prefix command was added, which features several new
+   pushing variants.  Previously only one pushing command existed and
+   it had to be controlled using prefix arguments, which was very
+   cumbersome.
+
+ * The various tagging commands are now suffix commands of the new
+   tagging prefix command.
+
+ * It is now possible to stash, or create a snapshot from, just the
+   staged or the unstaged changes, instead of both.  Suffix commands
+   for branching, listing, and showing stashes were added to the
+   stashing prefix
+
+ * When creating stashes the new implementation in `magit-wip.el' is
+   used instead of `git stash'.  This allows the user to create
+   snapshot stashes without touching any files in the working tree.
+
+ * The submodule prefix now features new suffix commands for adding,
+   setting up, and fetching modules.
+
+ * Submodules with unmerged commits can now be displayed in the status
+   buffer.  Sections representing submodules can be expanded to show
+   their unpulled commits.  These commits can be acted on like commits
+   belonging to the super-project.
+
+ * Support for displaying diffs inside the log buffer instead of in a
+   separate diff buffer has been removed.  It might come back one day,
+   but the old implementation had just fallen behind regular one-line
+   log too much.
+
+ * The logging prefix features many new infix arguments and suffix
+   commands, which can now be combined in more flexible ways than
+   before.
+
+ * Many commands that previously read a single commit, branch, or
+   file in the minibuffer, can now read multiple, comma-separated items
+   from the user, while providing completion candidates for all of
+   them.  Likewise, when selecting a range, completion is available
+   for the second commit too.
+
+ * All of Git's reset variants are now exposed as individual commands,
+   but not all of them have a key binding by default.
+
+This was just the tip of the iceberg.
+
 Authors
 -------
 
-  1913  Jonas Bernoulli
+  2187  Jonas Bernoulli
     28  Sebastian Wiesner
-    19  Kyle Meyer
+    25  Kyle Meyer
+    19  Noam Postavsky
     17  Pieter Praet
-    16  Noam Postavsky
     12  Rémi Vanicat
      9  Florian Ragwitz
+     5  Philippe Vaucher
      5  Ramkumar Ramachandra
      4  Cornelius Mika
      4  Kan-Ru Chen
-     4  Philippe Vaucher
+     4  Syohei Yoshida
+     3  Alex Dunn
+     3  Alex Kost
      3  Nicolas Richard
-     2  Alex Kost
      2  Eric Schulte
+     2  Ingo Lohmar
      2  Mitchel Humpherys
      2  Peter Eisentraut
      2  Ryan C. Thompson
-     2  Syohei YOSHIDA
      1  Adeodato Simó
      1  Andrew Schwartzmeyer
      1  Andy Sawyer
      1  Bradley Wright
      1  Guillaume Martres
-     1  HUANG Wei
      1  John Mastro
      1  John Wiegley
      1  Julien Danjou
+     1  Lingchao Xin
      1  Mark Oteiza
      1  Michael Fogleman
      1  Michael Griffiths
      1  Michal Sojka
+     1  Natalie Weizenbaum
+     1  Oleh Krehel
+     1  Peter Vasil
      1  Rüdiger Sonderfeld
+     1  Steven E. Harris
      1  Teemu Likonen
+     1  Thomas A Caswell
+     1  Tim Perkins
      1  Tim Wraight
+     1  Wei Huang
+     1  Xavier Noria