own branch namespace.
     With the separate remote layout, you say 'git branch next
     origin/next', which allows you to use the matching name
     'next' for your own branch.  It also allows you to track a
     remote other than 'origin' (i.e. where you initially cloned
     from) and fork off of a branch from there the same way
     (e.g. "git branch mingw j6t/master").

   Repositories initialized with the traditional layout continue
   to work.

 - New branches that appear on the origin side after a clone is
   made are also tracked automatically.  This is done with an
   wildcard refspec "refs/heads/*:refs/remotes/origin/*", which
   older git does not understand, so if you clone with 1.5.0,
   you would need to downgrade remote.*.fetch in the
   configuration file to specify each branch you are interested
   in individually if you plan to fetch into the repository with
   older versions of git (but why would you?).

 - Similarly, wildcard refspec "refs/heads/*:refs/remotes/me/*"
   can be given to "git-push" command to update the tracking
   branches that is used to track the repository you are pushing
   from on the remote side.

 - git-branch and git-show-branch know remote tracking branches
   (use the command line switch "-r" to list only tracked branches).

 - git-push can now be used to delete a remote branch or a tag.
   This requires the updated git on the remote side (use "git
   push <remote> :refs/heads/<branch>" to delete "branch").

 - git-push more aggressively keeps the transferred objects
   packed.  Earlier we recommended to monitor amount of loose
   objects and repack regularly, but you should repack when you
   accumulated too many small packs this way as well.  Updated
   git-count-objects helps you with this.

 - git-fetch also more aggressively keeps the transferred objects
   packed.  This behavior of git-push and git-fetch can be
   tweaked with a single configuration transfer.unpacklimit (but
   usually there should not be any need for a user to tweak it).

 - A new command, git-remote, can help you manage your remote
   tracking branch definitions.

 - You may need to specify explicit paths for upload-pack and/or
   receive-pack due to your ssh daemon configuration on the
   other end.  This can now be done via remote.*.uploadpack and
   remote.*.receivepack configuration.


* Bare repositories

 - Certain commands change their behavior in a bare repository
   (i.e. a repository without associated working tree).  We use
   a fairly conservative heuristic (if $GIT_DIR is ".git", or
   ends with "/.git", the repository is not bare) to decide if a
   repository is bare, but "core.bare" configuration variable
   can be used to override the heuristic when it misidentifies
   your repository.

 - git-fetch used to complain updating the current branch but
   this is now allowed for a bare repository.  So is the use of
   'git-branch -f' to update the current branch.

 - Porcelain-ish commands that require a working 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.