Git 1.7.8-rc0

I just tagged 1.7.8-rc0 so that we can have something reasonable by late November before many in the US will stop working and start stuffing themselves. There are a few topics that I would further merge down before -rc1 but from the point of view of new features, this should be pretty much it for the upcoming release. Please test thoroughly to hunt for regressions.

Git 1.7.7.1

The latest maintenance release Git 1.7.7.1 is available.


The release tarballs are found at:


    http://code.google.com/p/git-core/downloads/list


and their SHA-1 checksums are:


9200e0b8ee543d297952b78aac8f61f8b3693f8e  git-1.7.7.1.tar.gz
b25dacb07ebbfc37e7a90c3d47f76b4c0f0487d9  git-htmldocs-1.7.7.1.tar.gz
419c750617ae0c952e2e43f0357c16de6ebc0a44  git-manpages-1.7.7.1.tar.gz


Also the following public repositories all have a copy of the v1.7.7.1
tag and the maint branch that the tag points at:


  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Have fun...

Git calendar redrawn

Updated Git calendar for the current development cycle is available here. Partly because the previous cycle took longer than was planned due to the outage of kernel.org, we already had many well cooked topics held back in the 'next' branch when we released 1.7.7, and this cycle is progressing in a rather rapid pace compared to the previous cycles.

Final Jeopardy by Stephen Baker

Finished reading Final Jeopardy, covering the popular game show match between IBM's Watson and human champions. The pace of the book was pleasant; not too slow to be boring, not too fast to be sketchy. I do not regularly watch television, but I recall people gathering in front of the large TV in our building in one afternoon watching it.

The author excellently described in easy terms why this "question answering" was a harder problem than just finding documents that contain words with search engines. The machine needs to understand (or at least "pretend as if it understands") synonyms and concepts to a certain degree to give plausible answer to clues expressed in human language.

I however found the "search engines are dumb, machine needs to go one level higher" a somewhat antiquated notion, after recently seeing results from Google and Bing for "cartoon about pc and mac users updating software", "movie in which scientists go to brain in submarine" and such.

Beginning 1.7.8 cycle

Now that 1.7.7 release was made, I started looking at the topic branches that have been cooking (and some have been stagnating), to get a better feel of what the next release would look like.

One of the major focus would be robustness and security. Partly because the 1.7.7 cycle overlapped with the much publicised k.org break-in, there have been a lot of discussions, both on and off git@vger.kernel.org mailing list, to offer our users better tools to leave audit trails and help them be more confident about the objects and histories they exchange over the wire.
Some randomly selected topics, either already implemented or still under discussion & consideration, are:

• Teach "git fetch" and "git push" (the object and history transfer over the wire) to validate the objects transferred from the other side of the network more thoroughly while storing them in the local object store before updating the local history pointer. "git push" already had a support for this (receive.fsckobjects) to protect the server side, but the same check will be supported for "git fetch" to give better assurance to the general public;
• In addition, teach "git fetch" and "git push" to make sure that the set of objects received from the other side of the network is actually consistent with the history the other end claims to be transferring;
• Signed push, where the server can require the history being uploaded to be cryptographically signed by the developer's public key;
• Signed commit, where the developer can cryptographically sign a commit without using a separate signed tag.

As usual, I am sure there will be ideas from different contributors during the development cycle toward 1.7.8, and some of them will be part of 1.7.8 and others may have to wait until the next cycle.

One unrelated area that I would like to see more development is to support "floating" submodules, for which the commit object name recorded in the superproject tree takes lower precedence than the actual branch state of submodules, so that the top level superproject can say "module M must check out the latest and greatest of its B branch". This goes quite against the distributed nature of Git, where "latest and greatest" for a given branch depends on which repository you are talking about, but in a project that uses a central shared repository workflow, it makes sort of sense.

A possible implementation would be to record that branch B in the submodule M should be checked out in .gitmodules of the superproject, and "git submodule update M" would check out the local branch "B" (which must integrate with remotes/origin/B), if exists, instead of what is recorded at path M in the superproject tree. Some codepaths e.g. "git status", "git diff", that are run in the superproject currently assume that they always have to compare .git/HEAD in the submodule M with what is in the superproject tree at M, and need to be updated to compare remotes/origin/B and heads/B in submodule M for such a submodule.

By the way, I'll likely to change the repository signing key in the near future. The current key in use is:

pub   1024D/F3119B9A 2004-01-28
      Key fingerprint = 3565 2A26 2040 E066 C9A7  4A7D C0C6 D9A4 F311 9B9A
uid                  Junio C Hamano <gitster@pobox.com>

and I do not have any reason to believe the key might have been compromised (it never left my home machine), I've updated along with other k.org users. The new GPG key will be:

pub   4096R/713660A7 2011-10-01
      Key fingerprint = 96E0 7AF2 5771 9559 80DA  D100 20D0 4E5A 7136 60A7
uid                  Junio C Hamano <gitster@pobox.com>

You can obtain both of them at http://pgp.mit.edu/ and other quality keyservers.