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