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.

Git 1.7.7

The latest feature release Git 1.7.7 is available.

The release tarballs are found at:

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

and their SHA-1 checksums are:

bbf85bd767ca6b7e9caa1489bb4ba7ec64e0ab35  git-1.7.7.tar.gz
33183db94fd25e001bd8a9fd6696b992f61e28d8  git-htmldocs-1.7.7.tar.gz
75d3cceb46f7a46eeb825033dff76af5eb5ea3d9  git-manpages-1.7.7.tar.gz

Also the following public repositories all have a copy of the v1.7.7 tag and the master 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


The release tag and the tarballs can be verified with my GPG key if anybody is so inclined. To get my public key:

  $ git fetch git://repo.or.cz/alt-git.git refs/tags/junio-gpg-pub
  $ git rev-parse FETCH_HEAD
  680865b90b18efbc9402ea979adf0302c6dfe72e
  $ git cat-file blob FETCH_HEAD | gpg --import

and then make sure that you got my key by checking the output from "gpg --fingerprint", which should contain these lines:

  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>

The tarball description at http://code.google.com/p/git-core/downloads/list contains the same list of SHA-1 checksums shown above and signed with my GPG key.

Have fun.

Git v1.7.7 Release Notes
========================

Updates since v1.7.6
--------------------

 * The scripting part of the codebase is getting prepared for i18n/l10n.

 * Interix, Cygwin and Minix ports got updated.

 * Various updates to git-p4 (in contrib/), fast-import, and git-svn.

 * Gitweb learned to read from /etc/gitweb-common.conf when it exists,
   before reading from gitweb_config.perl or from /etc/gitweb.conf
   (this last one is read only when per-repository gitweb_config.perl
   does not exist).

 * Various codepaths that invoked zlib deflate/inflate assumed that these
   functions can compress or uncompress more than 4GB data in one call on
   platforms with 64-bit long, which has been corrected.

 * Git now recognizes loose objects written by other implementations that
   use a non-standard window size for zlib deflation (e.g. Agit running on
   Android with 4kb window). We used to reject anything that was not
   deflated with 32kb window.

 * Interaction between the use of pager and coloring of the output has
   been improved, especially when a command that is not built-in was
   involved.

 * "git am" learned to pass the "--exclude=<path>" option through to underlying
   "git apply".

 * You can now feed many empty lines before feeding an mbox file to
   "git am".

 * "git archive" can be told to pass the output to gzip compression and
   produce "archive.tar.gz".

 * "git bisect" can be used in a bare repository (provided that the test
   you perform per each iteration does not need a working tree, of
   course).

 * The length of abbreviated object names in "git branch -v" output
   now honors the core.abbrev configuration variable.

 * "git check-attr" can take relative paths from the command line.

 * "git check-attr" learned an "--all" option to list the attributes for a
   given path.

 * "git checkout" (both the code to update the files upon checking out a
   different branch and the code to checkout a specific set of files) learned
   to stream the data from object store when possible, without having to
   read the entire contents of a file into memory first. An earlier round
   of this code that is not in any released version had a large leak but
   now it has been plugged.

 * "git clone" can now take a "--config key=value" option to set the
   repository configuration options that affect the initial checkout.

 * "git commit <paths>..." now lets you feed relative pathspecs that
   refer to outside your current subdirectory.

 * "git diff --stat" learned a --stat-count option to limit the output of
   a diffstat report.

 * "git diff" learned a "--histogram" option to use a different diff
   generation machinery stolen from jgit, which might give better
   performance.

 * "git diff" had a weird worst case behaviour that can be triggered
   when comparing files with potentially many places that could match.

 * "git fetch", "git push" and friends no longer show connection
   errors for addresses that couldn't be connected to when at least one
   address succeeds (this is arguably a regression but a deliberate
   one).

 * "git grep" learned "--break" and "--heading" options, to let users mimic
   the output format of "ack".

 * "git grep" learned a "-W" option that shows wider context using the same
   logic used by "git diff" to determine the hunk header.

 * Invoking the low-level "git http-fetch" without "-a" option (which
   git itself never did---normal users should not have to worry about
   this) is now deprecated.

 * The "--decorate" option to "git log" and its family learned to
   highlight grafted and replaced commits.

 * "git rebase master topci" no longer spews usage hints after giving
   the "fatal: no such branch: topci" error message.

 * The recursive merge strategy implementation got a fairly large
   fix for many corner cases that may rarely happen in real world
   projects (it has been verified that none of the 16000+ merges in
   the Linux kernel history back to v2.6.12 is affected with the
   corner case bugs this update fixes).

 * "git stash" learned an "--include-untracked option".

 * "git submodule update" used to stop at the first error updating a
   submodule; it now goes on to update other submodules that can be
   updated, and reports the ones with errors at the end.

 * "git push" can be told with the "--recurse-submodules=check" option to
   refuse pushing of the supermodule, if any of its submodules'
   commits hasn't been pushed out to their remotes.

 * "git upload-pack" and "git receive-pack" learned to pretend that only a
   subset of the refs exist in a repository. This may help a site to
   put many tiny repositories into one repository (this would not be
   useful for larger repositories as repacking would be problematic).

 * "git verify-pack" has been rewritten to use the "index-pack" machinery
   that is more efficient in reading objects in packfiles.

 * test scripts for gitweb tried to run even when CGI-related perl modules
   are not installed; they now exit early when the latter are unavailable.

Also contains various documentation updates and minor miscellaneous
changes.


Fixes since v1.7.6
------------------

Unless otherwise noted, all fixes in the 1.7.6.X maintenance track are
included in this release.

 * "git branch -m" and "git checkout -b" incorrectly allowed the tip
   of the branch that is currently checked out updated.

Git 1.7.7-rc3 and 1.7.6.4 are out

I gave up waiting on kernel.org and really wanted to do the 1.7.7 final toward this weekend, but found a corner case regression in the recursive merge backend (again). 1.7.7-rc3 contains a quick fix for it, and needs to be cooked for a few days at least, so the final will have to wait at least until mid next week.

1.7.6.4 merges a handful of fixes that have already been merged to the master branch and are included in 1.7.7-rc3.

They are both available at

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

and also are found in my public repositories at various hosting sites:

        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

Return of html/man branches

I have not built and published these two branches myself for quite some time, as I let the post update hook of my public repository automatically fetch updates from the 'master' branch to another work area, format the documentation, make commits and push the result back to the public repository, all automated at the kernel.org infrastructure.

Unfortunately, kernel.org has been down for quite a while. So as a "time-permits" and "experimental" basis, I've started publishing these two branches after formatting the documentation locally on my primary development machine to the other public repositories.

I won't promise that I'll rebuild the docs every time I push the 'master' branch out, like the system I used to have at kernel.org did for me, but this will have to do in the meantime.

https://git-core.googlecode.com/git-history/html/git.html

Fun with url.$that.insteadOf

It is not exactly fun that I and others have to do this, but while k.org is down:

$ git -c url.http://code.google.com/p/git-core.insteadof=git://git.kernel.org/pub/scm/git/git.git fetch

lets me reuse all the fetch refspec configuration items I have for the "origin" remote.

To make this semi-permanent, I could have the following in my $HOME/.gitconfig but I have been hoping that k.org would come back before I actually do it and haven't done so:

[url "http://code.google.com/p/git-core"]

  insteadOf = git://git.kernel.org/pub/scm/git/git.git

Not exactly fun, but...

Git User's Survey 2011

Here is from Jakub Narebski who is again running "Git User's Survey" this year for us.


The Git User's Survey 2011 is now up! Please devote a few minutes of
your time to fill out the simple questionnaire; it'll help the Git
community understand your needs, what you like about Git (and what you
don't), and overall help us improve it.

The survey will be open from 5 September till 3 October 2011.

The results will be published at GitSurvey2011 page on Git Wiki.