It's been a while since the last feature release, and I think with the recent "many things built-in" (including the busybox style integration) we are nearing a good time to do the next feature release 1.4.0. Before doing a 1.4.0-rc1, I would like to see the following topics in the "next" branch graduate to "master": - re-add missing flags to format-patch. I have resurrected "--signoff"; if people care about something else we dropped when we went built-in, please raise hand and submit patches. - tree-parser updates from Linus seems to be fine in the sense I haven't seen breakage from it; I'll push it out to "master" before the end of the week. I'd like to do another round of update to introduce a unified tree/index/directory walker, so settling this down is sort of urgent. - http-fetch fixes from Nick, which looked obviously correct. I would appreciate test reports from people who saw breakages on this one. - reflog from Shawn. Do people find this useful? I've enabled reflog on "next" branch in my development repository to see how useful it would be for myself a few days ago, and also in a linux-2.6 repository I use for testing (I do not hack on kernel myself). Other topics in "next" includes: - read/write-tree --prefix. This is remnant of now-vetoed subproject support using "bind commit". I kept both of them because they could be useful independent of "bind commit", but I do not know how much. I think read-tree --prefix might probably be more useful than write-tree --prefix, since the latter can be writing out the whole tree and run rev-parse $tree:/path/name to extract that part, but the former does not have an easy equivalent (you could pipe ls-tree output to sed and pipe that to update-cache --index-info, but that is crumsy). I'd like to do "gitlink" based subproject support but most likely that needs to come after tree/index/directory walker. - fetch-pack client-side hack. When your repository has more roots than the repository you are fetching from, the common commit discovery exchange between fetch-pack and upload-pack ends up traversing down the ancestry chain of the history the other end do not have. The hack in the "next" branch is to give up the common commit discovery early on the client side, which Ralf Baechle who originally reported the problem says to fix the problem (<20060526154239.GA20839@xxxxxxxxxxxxxx>); but the proper fix involves a bit smarter upload-pack. I've posted a hacky upload-pack patch: <7vfyiwi4xl.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> but I think it should really needs to be cleaned up properly. Things that we might want to have in 1.4.0 but not even in "next" yet include: - p4 importer (Sean Estabrooks) -- are people interested? - letting fetch-pack to ask for an arbitrary commit object the user obtained out of band (Eric W Biederman) -- waiting for updated patch. We would need a corresponding one-liner patch to upload-pack when we do this. - using ~/.gitrc to give a fall-back default when $GIT_DIR/config does not have values. - command aliases and possibly default arguments via the configuration file. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html