tree refuses to
   work in a bare repository.


* Reflog

 - Reflog records the history from the view point of the local
   repository. In other words, regardless of the real history,
   the reflog shows the history as seen by one particular
   repository (this enables you to ask "what was the current
   revision in _this_ repository, yesterday at 1pm?").  This
   facility is enabled by default for repositories with working
   trees, and can be accessed with the "branch@{time}" and
   "branch@{Nth}" notation.

 - "git show-branch" learned showing the reflog data with the
   new -g option.  "git log" has -g option to view reflog
   entries in a more verbose manner.

 - git-branch knows how to rename branches and moves existing
   reflog data from the old branch to the new one.

 - In addition to the reflog support in v1.4.4 series, HEAD
   reference maintains its own log.  "HEAD@{5.minutes.ago}"
   means the commit you were at 5 minutes ago, which takes
   branch switching into account.  If you want to know where the
   tip of your current branch was at 5 minutes ago, you need to
   explicitly say its name (e.g. "master@{5.minutes.ago}") or
   omit the refname altogether i.e. "@{5.minutes.ago}".

 - The commits referred to by reflog entries are now protected
   against pruning.  The new command "git reflog expire" can be
   used to truncate older reflog entries and entries that refer
   to commits that have been pruned away previously with older
   versions of git.

   Existing repositories that have been using reflog may get
   complaints from fsck-objects and may not be able to run
   git-repack, if you had run git-prune from older git; please
   run "git reflog expire --stale-fix --all" first to remove
   reflog entries that refer to commits that are no longer in
   the repository when that happens.


* Cruft removal

 - We used to say "old commits are retrievable using reflog and
   'master@{yesterday}' syntax as long as you haven't run
   git-prune".  We no longer have to say the latter half of the
   above sentence, as git-prune does not remove things reachable
   from reflog entries.

 - There is a toplevel garbage collector script, 'git-gc', that
   runs periodic cleanup functions, including 'git-repack -a -d',
   'git-reflog expire', 'git-pack-refs --prune', and 'git-rerere
   gc'.

 - The output from fsck ("fsck-objects" is called just "fsck"
   now, but the old name continues to work) was needlessly
   alarming in that it warned missing objects that are reachable
   only from dangling objects.  This has been corrected and the
   output is much more useful.


* Detached HEAD

 - You can use 'git-checkout' to check out an arbitrary revision
   or a tag as well, instead of named branches.  This will
   dissociate your HEAD from the branch you are currently on.

   A typical use of this feature is to "look around".  E.g.

	$ git checkout v2.6.16
	... compile, test, etc.
	$ git checkout v2.6.17
	... compile, test, etc.

 - After detaching your HEAD, you can go back to an existing
   branch with usual "git checkout $branch".  Also you can
   start a new branch using "git checkout -b $newbranch" to
   start a new branch at that commit.

 - You can even pull from other repositories, make merges and
   commits while your HEAD is detached.  Also you can use "git
   reset" to jump to arbitrary commit, while still keeping your
   HEAD detached.

   Remember that a detached state is volatile, i.e. it will be forgotten
   as soon as you move away from it with the checkout or reset command,
   unless a branch is created from it as mentioned above.  It is also
   possible to rescue a lost detached state from the HEAD reflog.


* Packed refs

 - Repositories with hundreds of tags have been paying large
   overhead, both in storage and in runtime, due to the
   traditional one-ref-per-file format.  A new command,
   git-pack-refs, can be used to "pack" them in more efficient
   representation (you can let git-gc do this for you).

 -