GitTogether 2008
What happens when a dozen Git developers get together for beers after an all day Git conference? Patches like this: Subject: [PATCH 1/1] diff: support making output friendlier for fine,…
What happens when a dozen Git developers get together for beers after an all day Git conference? Patches like this:
Subject: [PATCH 1/1] diff: support making output friendlier for fine, grand users
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Scott Chacon <schacon@gmail.com>
Signed-off-by: Tom Preston-Werner <tom@github.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: J.H. <warthog19@eaglescrag.net>
Signed-off-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Kai Blin <kai@samba.org>
Acked-by: Petr Baudis <pasky@suse.cz>
Enabled-by: Cascade "Smooth" Amber <clarity@tiedhouse.com>
---
diff.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index e368fef..0e2c14a 100644
--- a/diff.c
+++ b/diff.c
@@ -2489,6 +2489,9 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
else if (!prefixcmp(arg, "--output=")) {
options->file = fopen(arg + strlen("--output="), "w");
options->close_file = 1;
+ }
+ else if (!strcmp(arg, "--pirate")) {
+ printf("Arrrr! These be yer fine changes, me 'earty!!n");
} else
return 0;
return 1;
--
1.5.4.5
The second annual GitTogether concluded today, which consisted of a few dozen core git developers and evangelists that met at Google (who graciously hosted and fed us) for the last three days. I had a great time, finally meeting in person a really significant group of Git developers who have literally written most of Git. Junio Hamano, Shawn Pearce, Johannes Schindelin, Eric Wong, Jeff King, Petr Baudis, Christian Couder, and Nick Hengeveld were all there, and have alone probably written more than half of the existing codebase.
On Tuesday night, A Large Angry SCM donated beer money for us all, and the above patch was the final outcome of that night. What is more Gitish than a dozen geeks passing around a laptop with an awesome patch so everyone can sign off on it, then four core Git developers trying to figure out how to use git send-email for 10 minutes? Good times.
Over the three days, besides a good amount of laughing and joking (at one point Jeff had a ‘git log –swedish-chef’ working, I think), there were some really interesting things discussed. Tom got to demonstrate GitHub and Gist to the group, most of whom are very command line oriented and had not used either before. I got to talk about the need for a linkable git library and Johannes found someone else (not with the GitTogether, but at Google with the OpenAFS project at the same time) that might be able to work with me on that (and in getting a TortoiseSVN-like client as well). I also got to show off my iPhone-based Git server work in progress that even got a few patches from David Symonds right after.
The whole thing started off with Johannes giving a nice tech talk on contributing with Git.
Sam demonstrated the work he went through to import 20 years of Perl history into the git repository that the Perl team is just now finishing transitioning to from Perforce. He also talked about the GitTorrent protocol, which we might be able to use at some point down the road to speed up git clones.
Shawn went over pack v4, which is a new packfile format, which was completely fascinating to me, but likely not to anyone who would be reading this blog entry. Basically it would speed up some operations by keeping commit and tree data in binary form in the packfile, rather than in deflated text form. Shawn also spoke about the status of the JGit project, which is the most complete re-implementation of Git around (it’s in Java).
Junio went though a sort of statistical history of the Git project that was fascinating (turns out there are still about 220 lines of code still around from Linus’s original first commit).
Tim talked about something that I think will be one of the next huge (highly visible) changes in Git you’re likely to see in the next year – handling large meda well, and being able to do narrow and sparse clones, (and shallow clones better). This means being able to clone part of a Git repository, such as just the last revision (shallow), just the ‘lib’ directory (narrow) or just a single file (sparse). Importantly, you would be able to see the history of everything still (it would download the commit and tree objects, which are generally small, but not the larger blobs), and you would be able to do pushes back (which shallow clones can’t currently do).
The other important, highly visual thing that was discussed, and even a few patches are already in for, is for little improvements to the UI. The full planning document is on Gist, but already things like making use of the term ‘stage’ for things that happen in the index (such as using ‘git diff –staged’ instead of ‘git diff –cached’) is being worked on. I’m excited that staging files may soon be done via ‘git stage’ rather-than/in-addition-to ‘git add’. This is nice for new users who often have a hard time seeing why you have to keep ‘git add’ing to stage your changes.
Overall, a really great conference, and I’m so glad that now I have faces to go along with nearly all the names I see on the list all the time. And even geeky drinking stories with some of them. Now we just need to get Junio (which, btw, he says is pronounced ‘June’) to accept the pirate patch…
Tags:
Written by
Related posts
Announcing 150M developers and a new free tier for GitHub Copilot in VS Code
Come and join 150M developers on GitHub that can now code with Copilot for free in VS Code.
GitHub Availability Report: November 2024
In November, we experienced one incident that resulted in degraded performance across GitHub services.
The top 10 gifts for the developer in your life
Whether you’re hunting for the perfect gift for your significant other, the colleague you drew in the office gift exchange, or maybe (just maybe) even for yourself, we’ve got you covered with our top 10 gifts that any developer would love.