What's new in git.git

Latest maintenance release for GIT 1.0 (1.0.8) and the new feature release GIT 1.1.0 have been pushed out.

Waiting in the proposed updates branch are two backward incompatible changes.

 - Require packfiles to be named pack-[0-9a-f]{40}.pack, and
   issue an warning if [0-9a-f]{40} part does not match the SHA1
   checksum of sorted object names that are contained in the
   pack.  Later I would like to promote the warning to an error,
   and there is a tool to help renaming packs created with older
   git-pack-objects.  When the warning is promoted to an error,
   this will break existing packfiles.

 - Use textual symbolic refs to represent .git/HEAD everywhere,
   not just on filesystems without symbolic link supports.  This
   was proposed by Pavel mid November 2005, but is known to
   break Porcelains that read(2) from .git/HEAD and expect to
   read an object name for the current branch head (use "git
   rev-parse --verify HEAD" instead), and write(2) into
   .git/HEAD and expect to update the current branch head (use
   "git update-ref HEAD $commit [$old]" instead).  Last time I
   checked, gitweb would break with this change.

Also there are patches floating around to update format-patch and rebase. I rejected the initial round, but consider what the latter wants to achieve a worthwhile goal, and expect to update rebase in some form.

Now the core and the barebone Porcelain are more or less stable and changes have significantly slowed down, I think it is a good time to start revisiting the libification effort, started by Smurf. I haven't taken a look at his tree for a while.

Another area that needs attention is to see how we can improve handling of merges between branches that have renamed things (i.e. HPA's klibc repositories). I'd also like to teach renaming merge to resolve strategy somehow.

Other small things I have in mind, in random order, are:

 - Give extra option to "diff-tree -m -p" to show difference
   between natural merge among parents and the actual merge
   result.  I do not think this would make sense for non patch
   format.

 - The recent "git-daemon --base=/pub/git" is a good addition
   (git://host/frotz.git is mapped to /pub/git/frotz.git
   directory), but with the current implementation whitelist
   needs to start with /pub/git/.  I initially thought it was
   not so nice, but maybe it is OK; but this needs to be
   documented.  It also forbids user relative paths, which
   should be made an independent switch.

 - Also in "git-daemon", I outlined --strict-symlink option a
   while ago, which forbids symbolic links to step outside of
   whitelisted areas.  This has not been implemented, and we may
   want to add it.

 - Although Linus has been pretty negative about improving the
   current dumb http transport, many people seem to rely on it.
   It "works" with packfiles in the sense that it does not barf,
   but the server file packing strategy to reduce duplicated
   download needs to be worked out to make it more efficient.

 - If the same cloning requests are made number of times, we
   should be able to cache the packfile we sent out and reuse,
   to reduce the load on the server side.  When used with
   git-daemon, this requires the daemon to be able to write
   somewhere (not necessarily the original repository itself),
   so there is certain security implications.