Junio C HamanoHere 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.
