What will happen to git.git in the near future

Here are some random thoughts on the short-term plan.  We are
currently at 1.4.2 release (and "maint" is at 1.4.2.1).

I do not know when the changes are big enough to start the 1.5
series, so tentatively I'll call the next one 1.4.3, the one
that follows 1.4.4, and so on, in the following description.

 - git-resolve is deprecated on "master" and will continue to be
   so until 1.4.3.  We will remove it before 1.4.4 happens.

 - We will deprecate the original merge-recursive written in
   Python by renaming it to merge-recursive-old, and make
   merge-recur to take its place.  1.4.3 will ship that way.
   Sometime in not so distant future we will remove
   merge-recursive-old and merge-recur, perhaps in 1.4.5.

 - We should deprecate git-tar-tree.  However, it has been
   around and advertised for quite some time, so we need to make
   sure people would not get burned too badly.  It might be
   worthwhile to rewrite git-tar-tree as a thin wrapper to
   "git-archive --format=tar" and remove git-upload-tar now (in
   other words, "git-tar-tree --remote" will continue to work,
   but it will talk with "git-upload-archive", not with
   "git-upload-tar" on the other end), release 1.4.3 with it
   with a deprecation warning, and then remove it in 1.4.5.

 - virtual hosting by git-daemon should be ready.  I will push
   it out to "master" before 1.4.3 release.

 - packed-refs still has a few issues before it can hit
   "master". 

   - deleting branches does not really work yet, as there have
     been some discussions on the list.

   - dumb transports are unaware of it.  Trying to fetch a
     ref that is packed would not work.

   I feel this series to be a significant enough change that
   deserve a bit careful handling.  Perhaps in 1.4.4 release.

 - The per-branch configuration to control git-fetch is Ok in
   itself, and we might want to push it out to "master" and
   release 1.4.3 with it in its current form.  But the topic
   might want to learn other tricks to have more comprehensive
   per-branch configuration support.  We will see how it plays
   out.

 - Git.pm lost Git.xs which hopefully would make it a bit easier
   to work for wider audiences.  Hopefully we can push it out to
   "master" soon and see if anybody screams.  Depending on what
   happens, it may be in 1.4.3 release.

 - git-show-ref and git-for-each-ref serve similar purpose (when
   viewed in a bigger picture) but with different interface and
   different set of features.  We should consolidate them into
   one command before they hit in any released version.

 - git-log's support for --committer=, --author= and --grep= is
   Ok by itself, but I feel we should do a bit more to make it
   useful.  Currently we cannot say "written by A and committed
   by B", or "written by C and have word D in the log".  Because
   the boolean logic between match patterns we use internally
   are line oriented, borrowing --and from git-grep is not
   enough ("--committer=A --and --author=B" would mean 'if the
   commit object has a header line that matches "^committer .*A"
   and "^author .*B" at the same time', which is not what we
   want).  We would need a "buffer-wide AND" that can express
   'see if there is a header line that matches "^committer .*A"
   and a header line, which may be different from the
   "committer" one, that matches "^author .*B"'.

   Implementing "buffer-wide AND" will involve updating git-grep
   but as a side effect we will also be able to say "find files
   that have word A and B in them", which would be a useful
   thing.  I'd push the current implementation out to "master"
   soon and release 1.4.3 with it, and defer implementation of
   the buffer-wide AND to a later version.

 - generation of version 3 pack files is 1.4.3 material.

 - new pack object format to express delta base object by the
   offset in the stream will start cooking in "next" soon; I
   just haven't got around to merge it yet.  I feel this to be
   significant enough change that can deserve a bit careful
   handling.  Perhaps in 1.4.4 or 1.4.5 release.

 - windowed mmap() of pack data is an important change (I do not
   mean to pressure Shawn by saying this) and needs to be cooked
   carefully.  I do not expect it to be ready until 1.4.5
   release at the earliest.