KernelTrap - source control

Git 1.5.6, "Relatively Small Impact Changes"

Jeremy — Thu, 19 Jun 2008 00:04:03 +0000

"As promised, this cycle was short and the release is with only relatively small impact changes," said Git maintainer Junio Hamano, announcing the release of Git v1.5.6. He noted that both gitk and git-gui have been updated. To improve portability, when running "git init", git now autodetects whether or not a filesystem is case insensitive, and updates a new configuration variable accordingly. Dependencies on the 'cpio' and 'curl' binaries have also been removed. Among the changes improving performance, the "git clone" command has been rewritten in C. Other changes include:

"'git bisect help' gives longer and more helpful usage information; 'git branch' (and 'git checkout -b') can be told to set up branch..rebase automatically, so that later you can say 'git pull' and magically cause 'git pull --rebase' to happen; 'git cherry-pick' and 'git revert' can add a sign-off; 'git commit' mentions the author identity when you are committing somebody else's changes; 'git log' and friends learned the '--graph' option to show the ancestry graph at the left margin of the output; 'git send-email' now can send out messages outside a git repository; 'git svn' learned --add-author-from option to propagate the authorship by munging the commit log message; new object creation and looking up in 'git svn; has been optimized."

Git Management

Jeremy — Tue, 20 May 2008 22:47:43 +0000

"Is there a write up of what you consider the 'proper' git workflow?" Theodore Ts'o asked Linux creator Linus Torvalds, "why do you consider rebasing topic branches a bad thing?" Linus replied, "rebasing branches is absolutely not a bad thing for individual developers. But it *is* a bad thing for a subsystem maintainer." He went on to differentiate between 'grunts' who write the code and 'managers' who primarily collect other people's code, "a grunt should use 'git rebase' to keep his own work in line. A technical manager, while he hopefully does some useful work on his own, should strive to make _others_ do as much work as possible, and then 'git rebase' is the wrong thing, because it will always make it harder for the people around you to track your tree and to help you update your tree." Linus compared his own patch management style and productivity from over six years ago before he started using BK and git, to his current style using git:

"You can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you. And you'd better select the 'let other people help you', because otherwise you _will_ burn out. It's not a matter of 'if', but of 'when'. [...] And when you're in that kind of ballpark, you should at least think of yourself as being where I was six+ years ago before BK. You should really seriously try to make sure that you are *not* the single point of failure, and you should plan on doing git merges. [...] I think a lot of people are a lot happier with how I can take their work these days than they were six+ years ago."

Git 1.5.5, "Available at the Usual Places"

Jeremy — Wed, 09 Apr 2008 16:26:12 +0000

"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."

GIT 1.5.4, "An Unusually Long Cycle"

Jeremy — Sat, 02 Feb 2008 20:13:29 +0000

"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."

Git on Windows

Jeremy — Mon, 19 Nov 2007 10:15:10 +0000

"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."

Git Interim Maintainer

Jeremy — Wed, 17 Oct 2007 12:08:23 +0000

"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. :)"

Linux: Using Git For More Than The Kernel

Jeremy — Mon, 15 Aug 2005 18:37:09 +0000

A discussion was raised as to whether or not GIT [story] would be a service that should be provided by development websites like SourceForge. Linus Torvalds suggested that this would be a good match-up. "The git architecture is admirably suited to an _untrusted_ central server," Linus explained, "ie exactly the SourceForge kind of setup." He went on to explain, "with git, developers don't have to trust SF, and if SF is down or something bad happens (disk crash, bad backups, whatever), you didn't 'lose' anything - the real development wasn't being done at SF anyway, it was a way to _connect_ the people who do real development."

As to whether or not this is likely to happen, Linus added, "it's possible that git usage won't expand all that much either. But quite frankly, I think git is a lot better than CVS (or even SVN) by now, and I wouldn't be surprised if it started getting some use outside of the git-only and kernel projects once people start getting more used to it. And so I'd be thrilled to have some site like SF support it."

Linux: Git Homepage

Jeremy — Mon, 08 Aug 2005 13:48:31 +0000

Petr Baudis announced the creation of a homepage for git, the directory content manager used to manage the Linux kernel. Git was originally written by Linus Torvalds in early April of 2005 [story], and is now maintained by Junio Hamano [story]. Other online resources available for the tool include a tutorial that walks through the process of setting up and using git, a man page, and the gitweb interface providing easy browsing of the many kernel trees managed by git. The new webpage explains:

"GIT falls into the category of distributed source code management tools, similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every GIT working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access to a central server."