First release candidate for Git 2.4

This release has a few changes in the user-visible output from Porcelain commands. These are not meant to be parsed by scripts, but the users still may want to be aware of the changes.

• Output from "git log --decorate" (and "%d" format specifier used in the userformat "--format=<string>" parameter "git log" family of commands take) used to list "HEAD" just like other branch names, separated with a comma in between. E.g.
  
       $ git log --decorate -1 master
       commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master)
       ...
  This release updates the output slightly when HEAD refers to the tip of a branch whose name is also shown in the output.  The above is shown as:
  
       $ git log --decorate -1 master
       commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD -> master)
       ...
  
• The phrasing "git branch" uses to describe a detached HEAD has been updated to match that of "git status". When the HEAD is at the same commit as it was originally detached, they now both show "detached at <commit object name>". When the HEAD has moved since it was originally detached, they now both show "detached from <commit object name>". Earlier "git branch" always used "from", even when the user hasn't moved HEAD since it was detached.

Otherwise, there are only minor fixes and documentation updates everywhere, and unusually low number of new and shiny toys ;-)

• "git log --invert-grep --grep=WIP" will show only commits that do not have the string "WIP" in their messages.
• "git push" has been taught a "--atomic" option that makes push to update more than one ref an "all-or-none" affair.
• Extending the "push to deploy" added in 2.3, the behaviour of "git push" when updating the branch that is checked out can now be tweaked by push-to-checkout hook. The "push to deploy" implementation in 2.3 has a bug that makes it impossible to bootstrap an empty repository (or an unborn branch), but it can be worked around by using this hook.
• "git send-email" used to accept a mistaken "y" (or "yes") as an answer to "What encoding do you want to use [UTF-8]? " without questioning.  Now it asks for confirmation when the answer looks too short to be a valid encoding name.
• "git archive" can now be told to set the 'text' attribute in the resulting zip archive.
• "git -C '' subcmd" used to refuse to work in the current directory, unlike "cd ''" which silently behaves as a no-op.
• The versionsort.prerelease configuration variable can be used to specify that v1.0-pre1 comes before v1.0.
• A new "push.followTags" configuration turns the "--follow-tags" option on by default for the "git push" command.

Please give it a good beating so that we can ship a successful v2.4 final at around the end of the month without regressions compared to v2.3 series.

Thanks.