"The latest feature release GIT 1.5.5 is available at the usual places," began Git maintainer Junio Hamano, adding "we kept this cycle just slightly over two months, as the previous 1.5.4 cycle was painfully tooooo long."

Git is a distributed version control system that was originally written by Linus Torvalds in April of 2005. It was written to be only a temporary replacement for BitKeeper, which Linus had been using to manage kernel source code since February of 2002. Junio Hamano took over maintainership of Git in July of 2005, and the tool has long since become quite popular outside of even Linux kernel development. Regarding the latest stable release, Junio highlighted some of the changes, including:

"Comes with git-gui 0.10.1; bunch of portability improvement patches coming from an effort to port to Solaris has been applied; 'git fetch' over the native git protocol used to make a connection to find out the set of current remote refs and another to actually download the pack data. We now use only one connection for these tasks; 'git commit' does not run lstat(2) more than necessary anymore; bash completion script (in contrib) are aware of more commands and options; a catch-all 'color.ui' configuration variable can be used to enable coloring of all color-capable commands, instead of individual ones such as 'color.status' and 'color.branch'; bash completion's prompt helper function can talk about operation in-progress (e.g. merge, rebase, etc.); 'git help' can use different backends to show manual pages and this can be configured using 'man.viewer' configuration; 'git gui' learned an auto-spell checking; 'git checkout' and 'git remote' are rewritten in C; two conflict hunks that are separated by a very short span of common lines are now coalesced into one larger hunk, to make the result easier to read."

"Google Summer of Code 2008 is on! Over the past three years, the program has brought together over 1500 students and 2000 mentors from 90 countries worldwide, all for the love of code. We look forward to welcoming more new contributors and projects this year," begins a page listing all the projects planning to participate in this year's GSoC. Among the numerous planned participtants there are many kernel projects, including DragonFly BSD, FreeBSD, Git, GNU/Hurd, Linux, Minix, and NetBSD.

Student applications for GSoC projects begin today, running through the end of the month. Read on for many of the participation announcements from the above projects. For more information about the GSoC, the program's FAQ explains:

"Google Summer of Code (GSoC) is a program that offers student developers stipends to write code for various open source projects. Google will be working with a several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Historically, the program has brought together over 1,500 students with over 130 open source projects to create millions of lines of code. The program, which kicked off in 2005, is now in its fourth year."

"The latest feature release GIT 1.5.4 is available at the usual places," began Git maintainer Junio Hamano. He continued, "it has been an unusually long cycle. 5 months since the last feature release 1.5.3 was really a bit too long. But I hope it was worth waiting for. Thanks everybody for working hard to improve it." He noted that there were 165 contributers resulting in 684 changed files, included 70,435 insertions and 28,984 deletions.

The Git distributed version control system was originally written by Linus Torvalds in April of 2005 to temporarily replace BitKeeper, which he had been using to manage kernel source code since February of 2002. Junio Hamano took over maintainership of Git a few months later, in July of 2005, and the tool has long since become quite popular outside of even Linux kernel development. Regarding the latest stable release, Junio highlighted some of the changes, including:

"Comes with much improved gitk, with i18n; comes with git-gui 0.9.2 with i18n; progress displays from many commands are a lot nicer to the eye; rename detection of diff family while detecting exact matches has been greatly optimized; 'git diff' sometimes did not quote paths with funny characters properly; various Perforce importer updates; 'git clean' has been rewritten in C; 'git push' learned --dry-run option to show what would happen if a push is run; 'cvs' is recognized as a synonym for 'git cvsserver', so that CVS users can be switched to git just by changing their login shell; 'git add -i' UI has been colorized; 'git commit' has been rewritten in C; 'git bisect' learned 'skip' action to mark untestable commits; 'git svn' wasted way too much disk to record revision mappings between svn and git, a new representation that is much more compact for this information has been introduced to correct this; in addition there are quite a few internal clean-ups."

"Yes, I know ... another tree, just what everyone wants," quipped James Bottomley, announcing his new merge candidate (-mc) tree:

"This one has a specific purpose: It's my tree tracking everyone else's git and quilt trees so I get early warning if there are going to be any merge issues. However, it struck me it might be useful to anyone wishing to track what's going upstream more closely."

James noted that his new tree is available in git, and being automatically built each night. "As you can see from the reverts and the skips, we have trouble even now (and that's after I fixed up most of the failures in SCSI). ACPI and the x86 trees clash hideously, so I kicked out x86. Jens' block tree has two patches which clash with Bart's ide quilt. Greg actually has one patch in his tree that clashes with one of mine." He also noted, "this tree is currently very storage centric (i.e. I haven't included net trees or quilts because I didn't think they'd be likely to clash with my SCSI trees). However, if it could be more generally useful, I could add other trees and quilts to it."

"This lovely dark 4am is as good an occasion as any to offer to you the 5th issue of the msysGit Herald, the not-quite-biweekly news letter to keep you informed about msysGit, the effort to bring one of the most powerful Source Code Management systems to the poor souls stuck with Windows," began Johannes Schindelin on the git mailing list. He noted that the project was finally concentrating on getting git to work on Windows, having finally gotten the installer working. The Git on MSys project home page notes,

"Unfortunately, Git on Windows is only officially supported using Cygwin. However, there is a fork (hopefully to be merged with 'official' git real soon now) which enables you to compile git using MinGW/MSys. It is a little bit tricky to get ahold of everything needed (MSys, iconv, Tcl/Tk, gcc, make, zlib, regex, etc.), so this project tries to provide a single .zip (actually, a 7-Zip packed installer) which you can unpack, and by double-clicking on msys.bat everything is set. You can start right away to hack on your favourite Source Code Management tool."

Paul Mackerras merged an updated version of gitk into his master branch. Gitk is a git repository browser. New features include improve searching, "thus you can now search for commits that modify certain files or directories, or commits that add/remove a given string, as well as searching for commits by commit message, author, committer or headline." Paul also noted two performance improvements, "gitk now uses a new graph layout algorithm, which means it doesn't have to generate the whole layout from top to bottom at startup time, making startup faster," and, "gitk caches the topology information used for the previous/next tag and branch information, making startup faster."

Linus Torvalds noted some display annoyances, but responded favorably to the performance improvements, "*huge* improvements. It is now really nice to start up gitk even on the full kernel history." He made some suggestions for additional improvements, then added, "but this has both the layout performance improvements and the fixes to only show selected files in the diff view by default, so I hope this gets merged into standard git soon.."

When asked how to best refer to kernels between official releases and release candidates, Linus Torvalds pointed to his automated git snapshots. "I still call them 'nightly snapshots', but they do in fact happen twice a day if there have been changes, so that's not technically correct," he noted. The latest snapshot is 2.6.23-git15, "this is an exact name, because you can go to kernel.org and look up the exact commit ID that was used to generate it (there's an 'ID' file associated with each snapshot there)." For git users, he suggested using the "git describe" command to get the git name, with the current head being named v2.6.23-6562-g8add244. He went on to explain that the name "tells you three things: (a) it's based on 2.6.23 (b) there's been 6562 commits since 2.6.23 and (c) the top-of-tree abbreviated commit is '8add244'."

When asked about the previously discussed usage of "-rc0" and other similar proposed naming conventions, Linus replied:

"Please don't use those names. They don't actually tell anything about where in the cycle it is, and as you can see above, there's been 6500+ commits since 2.6.23, so saying '2.6.23-rc0' or similar really isn't very helpful if anybody actually cares about just where in the release cycle you are."

"As most folks are probably now well aware, Junio has been offline for about 11 days and may still be offline for a little while more," Shawn Pearce explained regarding git maintainer Junio Hamano's recent absence from Git development. He noted, "I'm not going to get into the specific details as it is Junio's business and not mine. But I can say that my thoughts and prayers to $DEITY are with him and his family at this time, and I don't expect him to be rushing back to git work tomorrow. However I'm quite certain that Junio will return when he can."

Shawn continued on explaining, "I've decided to step up and try to fill Junio's shoes. To that end I am publishing a maint, master, next (and soon) pu branch from a new fork on repo.or.cz" He offered links to his new git development trees, and followed up in another email summarizing recent changes. He noted, "I based my branches on top of the last items published by Junio, and am hoping that he will be open to pulling directly from these before he starts working again. Junio obviously has the option not to pull from me, but if I do my job of interim maintainer well I can probably talk him into it. :)"

In a short discussion following a patch titled "fix abdhid mismerge", Al Viro noted troubles in tracking down the changeset that caused the problem, "what's the right way to trace the things like that? Linus?" Linus Torvalds, as the original author of git, replied, "in general, I'm afraid that merge errors are simply not very easy to find." He then offered some general tips for tracking down mis-merges, noting, "if anybody can come up with a better way to find these kinds of mis-merges, I'd love to hear about it." In regards to this particular case, he explained:

"'-c' is for regular combined merges: any file that was modified in both parents will show up as a combination of the diffs of both sides, while a file that was taken in its *entirety* is ignored.

"In this case that's exactly what you wanted. It's just too noisy to necessarily be the default, and you can still have a silent mis-merge if the merger picked *only* one side.

But in general, I suspect that '-c' is often a good thing to try if you cannot find the cause of some change in a regular commit, and suspect a merge error."

Jungseung Lee announced the first public release of gitstat, "a GPL'd, web-based git statistics/monitoring system." He explains, "it retrieves a specified git tree, analyzes changesets, and shows graphical information like the number of changesets per day, the number of people who submitted changesets for a specific version(tag), etc." The link above offers a graphical view of Linus' mainline 2.6 kernel tree, with daily commit statistics, monthly commit statistics, kernel release frequency, and per-author statistics. Jungseung noted:

"Gitstat was derived from kfm (kernel feature monitor) which was originally developed by Keun-Sik Lim and Sang-Bae Lee of Samsung Electronics and currently maintained and developed by Jeong-Seung Lee and Soon-Son Kwon(Shawn) of Samsung Electronics. Kfm was inspired from Jon Corbet of lwn.net when he analyzed the git tree and Greg KH when he presented similar status report at OLS2007. We thought it would be interesting information every day."

In an overwhelmingly large series of 556 patches, Joe Perches attempted to track down maintainers for a significant number of files within the Linux kernel source tree. He explained, "I grew weary of looking up the appropriate maintainer email address(es) to CC: for a patch", adding a new line format to the kernel MAINTAINERS file parsed by a new get_maintainer.pl script.

Much of the feedback was criticism of the large number of patches that flooded the inboxes of all subscribers to the Linux Kernel Mailing List. Others suggested that the information would be better extracted from Git than from source files. When Joe asked for better ideas for achieving his end goal, Alan Cox suggested, "working off the git tree as it shows who actually is making changes/updating stuff recently and why which is a major clue when tracing bugs". Chris Wright pointed out, "I think this data will easily become stale. What is the point again?" going on to add "between git (or gitweb), existing MAINTAINERS and a bit of common sense (or extra sleuthing), I never perceived a significant problem." Adrian Bunk countered, "for active kernel developers like you and me it's not a problem. But for other people it's non-trivial to always figure out who the maintainer of some part of the kernel is."

In a recent lkml thread, the idea of getting the entire Linux kernel history into a git repository was discussed. Linus Torvalds noted, "I actually tried to get something like this together back in the BK days and early in the SCO saga. It was pretty painful to try to find all the historic trees and patches - they're all in different format, and some of them are unreliable." He added, "I've been thinking about trying to re-create some really old history into git, but it's still a lot of work.. And obviously not very useful, just interesting from an archaeological standpoint." Much information on early Linux kernels is gathered at oldlinux.org, and Linus already has the full 2.5.0 to 2.6.12-rc2 history imported from BitKeeper available in git. Linus went on to talk about why git is better suited than BK was for building a complete kernel history:

"The good news is that git would be a lot more natural to the process of trying to create a history, because you could basically import random trees, and tag them as just independent trees, and then re-create the history after-the-fact by trying to stitch them all together. And if you find a new tree, you'd just re-stitch it - something that was very hard to do with BK (and BK generally wouldn't help you with keeping multiple independent trees around, and wouldn't generally accept the notion of re-doing the histories and keeping various versions of the histories around)."

In response to a recent merge request, Linus Torvalds explained how he preferred the request to be formatted, "please don't hide the branch name in the free-flowing text". He noted that he wanted the git URL indented and on it's own line, "so that I don't miss the right branch-name even by mistake." He went on to explain:

"I try to be careful, and I think I missed the branch-name just once (and noticed it when the diffstat didn't match), but this is something I want to teach every git user to know very intimately: make it impossible to make mistakes, by always keeping the whole git information together, and never mixed up with any free-flowing explanation."