First there was mr, then etckeeper. Now git-annex completes my triptych of software tools that use git in ways that were never intended.

Git's original tagline was "the stupid content tracker". Git-annex inverts that, by managing files with git, without checking their contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, checksumming time, or disk space.

I've been working on git-annex for two weeks, and have been trusting my data to it for a week. Not a little data, but terabytes spread amoung multiple archival drives, file servers, laptops, and portable USB drives. In situations too complex for unison or rsync to be of much use. Applying git to this problem in an unconventional way has simplified things enormously.

At this point it should be very usable, and solid. A package will be uploaded to Debian shortly; or git clone it.

comment 1

Joey I've been mulling a scheme like this for a while - trying to work out if it would work... and how to make it work... cant wait to try it!

Cheers!

Comment by Paul
git-annex is not unison ..

I think 2 subcommands are missing:

1: list-local -- this must list files present in local repo.

2: list-missing -- list missing files in local repo.

with these, syncing files can be easy

Cheers

Comment by Jamil
comment 3

@jamil I thought about adding those, but since git-annex does use symlinks, you can just use ls and look at the colors (red files don't have content available).

Similarly, du - L to see sizes.

Comment by joey
git-annex comment

I am extremely pleased to test this package and kudo's to you!

1 minor while c88d4939453845efee04da811d64aa41046f9c11:

dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if "debian/git-annex/usr/bin/git-annex" were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libutil.so.1 could be avoided if "debian/git-annex/usr/bin/git-annex" were not uselessly linked against it (they use none of its symbols).

regards,

dutchfish

Comment by wil
comment 5

That apparently useless linking against libdl has been annoying me. It seems that ghc --make sets that up, so I don't know how to avoid it.

Of course, since libdl is part of libc6, there is no actual extra dependency introduced, so arguable dpkg-shlibdeps should just not complain about it.

Comment by joey