First round of UGFWIINI results

Dear fans of Git,

a while ago I announced the UGFWIINI contest, a glorious battle of ideas how to

	Use Git For What It Is Not Indended

As most of you probably did not find my blog yet, this may come as a surprise to you, but it will not be the only surprise in this email.

I managed to collect 10 candidates already, and since I did all the hard work of collating them, I took the liberty of ordering them into a very subjective order of ugfwiininess (pronounced "You-gah-wee-knee-ness").

Please assist me while reading this mail by hitting your desk alternating between your two index fingers, increasing the frequency from 2 to 4 hertz throughout the mail.

Ready? Okay.

Number 10:

Sergio Callegari describes how to manage opendocument (openoffice.org) files in git in

	http://kerneltrap.org/mailarchive/git/2008/9/15/3305014

While this might strike some of you as pretty lame, in my opinion it is still something Git was not intended for: Never mind the title "stupid content tracker", Git was clearly intended to track source code stored as small ASCII files; otherwise, 'git diff' would not be such an integral part of Git.

Number 9:

Tim Ansell talked about managing large media with Git at the GitTogether:

	http://www.thousandparsec.net/~tim/media+git.pdf

This falls into the same category as number 10, but in addition it strains the assumption of Git that you can easily fit the contents of a file into memory, as well as the assumption that it is pretty easy (and meaningful) to make a diff from two versions of a file.

Number 8:

Avery Pennarun explains his endeavor of tracking windows with git...
"If I get a virus, I can 'git revert' it."
http://alumnit.ca/~apenwarr/log/?m=200901#21
 
Sverre remarks: "It even beats the way we use Git to track the MSys
installation in msysgit.git..."

This is also related to Martin Krafft's idea to sort of replace the Debian packaging management by using Git, but...

Number 7:

... actually does something like that: James Tucker implemented a port manager based on Git:

	http://github.com/raggi/source_ports

Number 6:

Dieter Plaetinck synchronizes Firefox profiles using Git:

	http://dieter.plaetinck.be/rethinking_the_backup_paradigm_a_higher-level_approach

Now, this even strains the definition of "content"...

Number 5:

David Abrahams archiving a large number of files (and detecting duplicates) uses Git partly for something it _can_ do, but certainly was not intended to do: identify duplicates.

	http://kerneltrap.org/mailarchive/git/2009/1/27/4827304

While the content-addressable filesystem has to deal with duplicates in the _time_ dimension very well (not many files are supposed to change from one revision to the next one, so most of the files _are_ duplicated), dealing with it in the _space_ dimension is not the purpose of Git, as can be seen by the lack of tool support for it (also keep in mind the absence of git-cp).

Number 4:

Josef Wolf asks in <20090131123336.GA1702@raven.wolf.lan> (with a fully valid Mail-Followup-To header) "How to move subdirectories from one svn repos to another."

"I would like to move a complete subdirectory with all its history from one svn repository to another."

Now, the ugfwiininess of this entry is definitely increased dramatically by Josef being inclined to go to Git _and back to Subversion_ again :-)

(Imagine a cheeky smirk on the face of your host.)

Number 3:

Jan Krueger's Git cookbook uses a Git repository as a backend of a content management system:

	http://repo.zoidberg.org/w/git-articledb.git
	http://gitrecipes.de/

This is related to the way my own blog works, but he was first. Credit where credit is due.

Number 2:

At the GitTogether, Sam Vilain presented his idea to use Git as a DB backend:

	http://utsl.gen.nz/talks/git-db

Just think about it: committing by "INSERT INTO"!

And now, ladies and gentlemen, please brace yourself for...

Number 1:

Scott Chacon's iGitHub: Running a git-daemon on an iPhone

	http://github.com/schacon/igithub/

This is so awesome as to defeat any attempt to describe it.

I hope you enjoyed the show, and see you again next time, on

	Using Git For What It Is Not Intended

(Now play your favorite jingle.)

Heya,

On Tue, Feb 17, 2009 at 17:47, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

How about using git to do a temporary 'svn stash'? If you have changes in your svn working copy that you cannot commit just yet, but you want to check out an earlier revision for whatever reason, the current only solution in svn to that is to have a second working copy. But no longer! $ cd path/to/svn/repo $ git init && git add . && git commit -m "save svn state" $ svn revert -R * $ svn update -r 42 $ # do whatever you need to do here $ git reset --hard && rm .git

Does that qualify? ;)

Hi,

On Tue, 17 Feb 2009, Sverre Rabbelier wrote:

Heh, do you actually use it?

Ciao, Dscho

On Wed, Feb 18, 2009 at 00:49, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Yup, at times when I need to work with an svn repository but cannot be bothered to rev up git-svn for it :).

also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2009.02.17.1747 +0100]:

A shame that I didn't see the contest start. I would have had a number of cases to add using Git

  - to track your ~ (cf. http://vcs-home.madduck.net)
  - to track /etc (cf. http://kitenet.net/~joey/code/etckeeper/)
  - as the backend for a service like snapshot.debian.net
  - as a mail store and complete replacement of IMAP

anyway, enter me for round 2!!

I had this idea? Well, maybe something related: vcs-pkg.org, which is about using distributed VCS for distro package maintenance. More Debian-specific is my goal to replace source packages with services that build straight from trees identified by Git tags, which I've written a bit about here:

  http://madduck.net/blog/2005.08.11:rcs-uploads/

This is up high on my list of todos, so expect more on this topic soon.

Anyway, thanks Johannes for the fun! :)

On Tue, Feb 17, 2009 at 06:39:57PM +0100, martin f krafft wrote:

Speaking of which I've done some initial testing a while ago (http://glandium.org/blog/?p=182) and done some archive-wide testing recently for which I still have to gather data and post about.

I also have some other use of git at work that I still have to post about.

Cheers,

Mike

Hi,

On Tue, 17 Feb 2009, martin f krafft wrote:

Sure!

But I deem the first two being trumped by the large media...

If you could point me to the IMAP thing, I'd be interested personally, as I use Git to track all my mails in maildir format.

Ciao, Dscho

Yes, that's what I meant.

You're very welcome!

Ciao, Dscho

To those wondering what happened to Dscho lately:

In Germany, there is this special time of the year called Fasching/Karneval/Fasenacht/... (carneval) where even the most serious patch bashers may turn into funny pals ;)

To Dscho:

Great work, I hope you'll go on past Ash Wednesday!

I'll work on my entry for the next contest, but the Top Ten are hard to beat...

Michael

I've been feeling a bit ugfwiinic all the afternoon and I couldn't realize why, but then I finally saw your post and I understood!

But Dscho, now I am sure that you missed that "git diff -odf" at the very core of git functionality that certainly Linus implemented on day one and that surely got lost due to an unfortunate SHA clash!

Ciao Sergio

Johannes Schindelin:

Which is very nice, it saved me several megabytes of disk space :-)

Still, I have "git diff" working fine for OpenOffice Writer documents here, using "oodiff" that I found somewhere I cannot remember...

Now, if only OpenOffice could be told not to store the documents as zip files, but rather as a directory, I wouldn't have to fool Git using the rezipper. Or perhaps one should implement support in Git to store zip files expanded (and just create the .zip on checkout)?

Then one could even merge conflicts between concurrent edits.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Errr... URL (of a blog), please?

Another candidate for UGFWIINI contest: Gitorial. Here is explanation

  ...this presentation was captured in the Git revision control
  system. Every commit has a commit message that explains the 'next
  slide' of the presentation. People can then view diffs between
  commits to quickly see what changed.

Well, it uses GitHub, not only Git, but...

http://github.com/blog/367-clojure-gitorial http://larrytheliquid.com/2009/03/02/presenting-clojure-with-a-gitorial

........................................................................

And similar thing: Homoiconic. Here is explanation

  Homoiconic is an experiment in publishing code and words about code
  on a small scale.

  When I write, I will add files to the homoiconic git repository,
  organized by date. Code will be included in the posts and also in
  the folder with the posts that discuss them, so it's easy to
  download what you like. You can even download the entire thing as an
  archive if you want.

http://github.com/raganwald/homoiconic

Hi,

On Tue, 3 Mar 2009, Jakub Narebski wrote:

Definitely.  Both are registered for the next round.

Ciao, Dscho

Jakub Narebski <jnareb@gmail.com> writes:

[...]
 

And here is yet another UGFWINII candidate: Flashbake. Here is explanation:

  Flashbake is a set of Python scripts that check your hot files for
  changes every 15 minutes, and checks in any changed files to a local
  git repository.  Flashbake records any changes made since the last
  check, annotating them with the current timezone on the
  system-clock, the weather in that timezone as fetched from Google,
  and the last three headlines with your by-line under them in your
  blog's RSS feed (I've been characterizing this as "Where am I,
  what's it like there, and what am I thinking about?"). It also
  records your computer's uptime.

  It is intendend illuminate the creative process in a way that often
  reveals the hidden stories behind the books we care about.

References:
===========
[1] "Flashbake: Free version-control for writers using git"
    by Cory Doctorow describes insporation for Flashbake
    http://www.boingboing.net/2009/02/13/flashbake-free-versi.html
    http://craphound.com/?p=2171
[2] "Cory Doctorow on Lifestreaming Contextual Snapshots Using New
    Tool Flashbake" by Mark Krynsky
    http://lifestreamblog.com/cory-doctorow-on-lifestreaming-contextual-snapshots-using-new-tool-flashbake/
[3] Flashbake announcement on its author blog
    http://thecommandline.net/2009/02/13/flashbake/
[3] Flashbake home page
    http://bitbucketlabs.net/flashbake/

Hi,

On Fri, 6 Mar 2009, Jakub Narebski wrote:

Thanks.  Accepted.

Ciao, Dscho

2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:

Does using Git to track edits when proofreading a html/text document (short story, novel, ...) count?

This is similar to the ODF <-> Git entry. Now all that needs to happen is to replace the ZIP format with a git repository and create a plugin for an ODF reader that makes git calls when doing the content tracking checks.

- Reece

Hi,

On Tue, 3 Mar 2009, Reece Dunn wrote:

I'll count it, but I want (read-only) access to the repository as a proof that you actually use Git that way ;-)

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Are you also in the contest, with your blog as one of the contenders?

Heya,

On Tue, Mar 3, 2009 at 17:04, Junio C Hamano <gitster@pobox.com> wrote:

I remember Dscho saying anything mentioned in the announcement does not count, but upon later inspection of the original post I cannot find it...?

Hi,

On Tue, 3 Mar 2009, Sverre Rabbelier wrote:

I thought so, too, but from the git log it does not seem like it. Of course, I sneakily rewrote history from time to time (so it should be in git log -g, but that computer is at home) ;-)

Ciao, Dscho

Hi,

On Tue, 3 Mar 2009, Junio C Hamano wrote:

As I am the jury, I decided to pretend that I have some decency left by not putting my own Git crim^Wuses into the contest...

;-)

Ciao, Dscho

On Tue, Mar 03, 2009 at 04:59:27PM +0100, Johannes Schindelin wrote:

Is it really that unusual? I've been keeping academic papers in git for years (and CVS before that -- blech), and I'm sure I'm not alone. Of course I'm writing in LaTeX, which is arguably a programming language. ;)

BTW, --color-words is indispensable when dealing with things that aren't line-oriented.

-Peff

Hi,

On Tue, 3 Mar 2009, Jeff King wrote:

Count me in.

I am interested in reading Reece's short stories, though.

Guess three times why I wrote --color-words...

You guessed it.  Academic papers written in LaTeX.

Ciao, Dscho

2009/3/3 Johannes Schindelin <Johannes.Schindelin@gmx.de>:

I am not writing them (at the moment :)). I am just using git to proofread stories by other people.

- Reece

On Tue, Mar 03, 2009 at 06:27:27PM +0100, Johannes Schindelin wrote:

I can only hope that they're git-themed (Linus fan-fiction?).

-Peff

Hi,

On Tue, 3 Mar 2009, Jeff King wrote:

No, that is an intended purpose of Git.  To worship Linus.

Thus, it would not qualify.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

[...]

And something very similar: "Using Git as a versioned data store in Python" by John Wiegley (similar to 'shelve' which uses database)

  http://www.newartisans.com/2008/05/using-git-as-a-versioned-data-store-in-python.html
  http://github.com/jwiegley/git-issues/

And similar solution for Ruby

  http://github.com/georgi/git_store

by the way of GitHub Blog: 

  http://github.com/blog/374-git-as-a-data-store-in-python-and-ruby

P.S. When there would be next round of UGFWIINI contest?

Hi,

On Wed, 11 Mar 2009, Jakub Narebski wrote:

Whenever I collected ten new participants...  You are helping ;-)

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

[...]

Not exactly UGFWIINI yet, but:

  "Music collaboration via git?"
  http://www.37signals.com/svn/posts/1655-music-collaboration-via-git
  (sharing LilyPond source files for music notation).

On Fri, Mar 27, 2009 at 08:08:04AM -0700, Jakub Narebski wrote:

I do something similar, though I am usually not writing in lilypond but rather in ABC or human-readable chord charts with accompanying lyrics. However, my band-mates are not git-literate, so I usually end up pulling their versions directly from email into the working tree, and then committing to git myself.

For added UGFWIINI, I also keep multitrack recording projects in the same repo. Live single tracks are kept as pristine "source", and then are mixed down (with filters and effects added) into a final product. It's even driven by make. ;)

However, the source files are annoyingly large to work with in git, so I keep them outside of the repo as immutable source and refer to them by unique name. Only the ways in which they are filtered or combined are in the repo.

-Peff

On 17 feb 2009, at 16:47, Johannes Schindelin wrote:

I would like to submit

	http://www.ordecon.com/2009/04/22/is-git-more-than-just-a-version-control-system/

for the next round :)