This survey ran from December 1st 2018-January 31st 2019.
git-annex v7 was recently released, with improved support for unlocked files in the repository which is planned to replace the old direct mode. Do you use any v7 repository features yet?
not yet (75%)
v7 unlocked files (7%)
adjusted unlocked branches (1%)
I'm still using direct mode (7%)
I don't know (7%)
Total votes: 263
Are you a command-line git-annex user, or do you use the git-annex assistant?
I use mostly the git-annex assistant (6%)
I use mostly git-annex at the command line (85%)
I use both equally often (4%)
I do not yet use git-annex (3%)
Total votes: 266
Pick the operating system which you use git-annex on the most.
Linux (84%)
OSX (9%)
Android (app) (0%)
Android (termux) (0%)
other Unix (0%)
Windows (native) (3%)
Widows Subsystem for Linux (WSL) (1%)
OpenBSD (0%)
Total votes: 264
How do you get git-annex installed?
From a prebuilt version on its website (12%)
I build from source (6%)
I install the version provided by my OS distributor (64%)
From a package manager not part of my OS (eg Nix, Homebrew) (11%)
I don't know; it was installed for me (0%)
Sometimes OS package manager, sometimes source (3%)
neurodebian repo (1%)
Total votes: 261
If you install it using different methods at different times, pick the method you use most frequently.
git-annex runs on many operating systems: Linux, OS X, BSDs, Android, and Windows. However, some ports are further along than others.
If there's a device on which you cannot use git-annex today, because the port to an OS is missing or incomplete, please pick it. Please don't vote for an OS where you already successfully use git-annex.
I'm good -- git-annex runs on my OSes of choice! (60%)
Windows (8%)
Android (19%)
Apple iOS (3%)
an ARM board not powerful enough to compile stuff on it. cross compiling haskell is a pain. So i rewrote the parts that i needed in another language (and i won't mention which one, i should be ashamed of this). (1%)
SmartOS (0%)
Synology NAS (app store package) (2%)
OpenBSD (1%)
MacOS - assistant is still flakey (0%)
MacOS - no tor integration (0%)
Total votes: 256
How many git-annex repositories do you have? If you have a bunch of clones of the same repository on different devices, count them all up or estimate.
0 (3%)
1 (7%)
2-5 (34%)
6-10 (20%)
11-25 (20%)
26-50 (8%)
51-100 (1%)
101-200 (1%)
201-300 (0%)
more! (1%)
Total votes: 254
How much data do you have stored in git-annex?
The way to get this value is to run git annex info .
and look for the line that says
"size of annexed files in working tree".
If you've got multiple repositories that each contain different files (not git clones), you can run it in each and add them up.
<1 GB (7%)
1+ GB (5%)
10+ GB (14%)
100+ GB (30%)
1+ TB (13%)
2+ TB (8%)
4+ TB (6%)
8+ TB (5%)
16+ TB (3%)
32+ TB (1%)
64+ TB (0%)
128+ TB (0%)
256+ TB (0%)
rather not say (0%)
I have too much data for git-annex to handle 
(0%)
Maggie here, I don't know this answer. (0%)
Total votes: 254
How would you characterize your general git knowledge? (Not your git-annex knowledge!)
novice (1%)
casual, needs advice (6%)
everyday use (20%)
can offer advice (40%)
know it very well (28%)
wrote some of it (2%)
Total votes: 256
Overall, how happy are you with git annex?
unhappy (1%)
not so happy (12%)
happy (42%)
very happy (24%)
completely ecstatic (1%)
one of my favorite applications of all time (16%)
Don't know, I just use NeuroDebian and PyMPVA (0%)
Total votes: 254
If a problem is preventing you from using git-annex, or the git-annex assistant, please indicate it here.
If you're currently using git-annex, you can instead answer on behalf of less technically adept friends or family, and identify a problem blocking them from using the git-annex assistant.
too hard to install (2%)
too hard to use (15%)
not good enough documentation (3%)
because of a bug (that has been reported) (1%)
because of a bug (that's not been reported yet) (1%)
because I don't think it's ready (1%)
don't trust the assistant (10%)
either git-annex gets confused often, or I do, so my use of it has started to stagnate (9%)
not issues personally, but people don't see (or realize they need) the immense benefits it provides (21%)
git-annex has many power features and good documentation of these features, but lacks many tutorials (like the walkthrough) showing new users how to tie the features together (12%)
without v7 there is a bit too much friction for non-technical user's file syncing needs. once v7 hits Debian stable etc. that will change. exciting times are ahead. (4%)
git alone is hard to grasp for a novice, with git-annex symlinks, locked/unlocked states, now adjusted branches -- it goes way too far to even grasp concepts. So hard to advice to naive users who did not yet get fascinated by git itself (6%)
do not work well over smb (0%)
git is not quite right as a data model, so there's lots of minor to serious friction when using git-annex to share data between different users or even just different contexts that want different views of the same data (1%)
problem with filenames across OSes (e.g., colons work with Linux but not under Windows) (0%)
difficult to use with Files/Nautilus (copy or drag&drop actually copies the symlink) (0%)
Integration with operating system not convenient enough. (0%)
My opinion could maybe be covered by Integration with operating system not convenient enough. (0%), not sure, but I'd thought that I would explain. First, I am a daily user of git, but the interactions and relationship between git and git-annex are not always clear to me, like for example renaming files (ther's no git-annex mv). Not sure if there's another way to do it, but I end up doing git mv; and similar for git-annex add and not having data commited until git-annex sync or manual commit. So I always feel as if it's not a complete tool and has to rely on git for some functionality, or that the user has to be aware of underlying concepts including git, which is much a bigger deal than software for storage and archives. The other big issue for me, perhaps unavoidable, is that symlinks are not exactly files, so this is covered by the Files/Nautilus answer, but also that one has to add -L for operations like du -shc *, or that the files don't get colored as media files with ls because again they are symlinks, not proper files. So it's tantalisingly close to be a normal directory with extra features like checksumming, archival and sharing between devices, but not in all aspects. As I said not sure if avoidable, so overall I prefer very much to use this software and have these features even with the glitches compared to usual files, thanks a lot! (0%)
Was unable to install it on OpenBSD (0%)
Lack of Github support (not your fault, of course) (0%)
Not apt for subsetting a big repo into a small storage device with crippled filesystem, which is what a dumb devices (say, MP3 player) would require and what I would consider a pretty common use scenario. For such a device, files would need to be unlocked, but that doubles the size of the repo, since annex.thin is not supported on such filesystems. (0%)
v7 is just way too slow sometimes. updating a (unchanged, or maybe one file changed) repo takes hours for a repo containing tens of thousands of files 
(0%)
I love the idea of git annex, but finding it hard to get confidence that I can get myself out of trouble. git makes it easy to get back to an earlier state, but I don't yet feel confident about that with git annex, despite it being just git -- the complexity and quirkiness make this harder. e.g. the issue with not being able to undo git add before first committing. More get out of trouble docs covering various situations might help. For example, for me right now, knowing some maybe hacky but performant v7-supported way to remove all the git data and just leave file content and structure behind (seems uninit and unannex don't yet tick the performant box) would help give me confidence to start using it seriously. Then I'd know I can just create a new annex when I get myself in serious trouble, until I understand things better. (0%)
loss of files' mtime info (for some reason year and month fields are preserved in metadata, but the rest is thrown away) (0%)
The major change from v5 to v7 adds a lot of confusion. Even though the issues are discussed fairly well in docs, novice users simply cannot navigate the docs effectively because of the persistence of relics of indirect/direct, locked/unlocked. It' (0%)
Terribly confusing for novice/beginning git users who rely on docs to figure things out, but cannot escape the presence of historical relics from v5 (direct, indirect, locked, unlocked). One is likely to pore over these difficult concepts for some time, then realize they're deprecated, then begin using in earnest, and only THEN realize that all repos default to v5 and that upgrading is not such a straightforward thing. I am still fighting this battle. Persisting because the product is just what i need at the end of the day. (0%)
needs an easy way to visualize the locations and status of files, so at a glance I can know if all my files are healthy and in the right places (0%)
I use git annex mostly from linux, sometimes from mac os. On mac OS it is very slow. I'd blame mas os filesystem, and the size of my repo. (0%)
Total votes: 222
(Note that missing ports covers ports to IOS etc, so don't add them here.)
git-annex is now 8 years old, and has a good number of users. What general area do you think development should focus on now?
just general maintenance, keep it working and fix bugs (13%)
make it easier for nontechnical users (31%)
make it more suitable for collaboration inside larger groups/organizations (ie, game developers, scientists, archivists) (19%)
port it to more platforms (0%)
performance (15%)
reliability (4%)
improve the existing ports (3%)
improve documentation (5%)
get more of the functionality merged into vanilla git, to have at least rudimentary interactions with git-only users (1%)
reliability features (e.g. being able to query when a file was last fsck'd on any device, consistent hashing to shard across devices) (2%)
features that widen applicability to data storage problems that are not currently well-served (think outside the box, eg. system backups, media galleries, large file sharing via email) (1%)
The documentation on configuration was not easy for me to use. I had to jump around lots of man pages to figure out how to specify a config option and where to place it. (0%)
metadata fast cache to make it usable on mid-large repos (0%)
Total votes: 238
Looking at git-annex's roadmap, which item seems most important to you?
Also feel free to write in an item from the todo list instead.
speed improvements (35%)
improve tree export (1%)
importing trees from special remotes (4%)
improve adjust --hide-missing interface (2%)
improve Windows support (13%)
more/collection of special remotes (0%)
deltas (8%)
Improve assistant on macos (2%)
I'm good without any of those (11%)
sharing files outside of git-annex easily (12%)
sync over tor (1%)
LFS API support (2%)
git-annex-assistant improvements (0%)
Improve installation. What about static linked compiled binaries for a few archs like I get with Go binaries? (0%)
git repo tracking (not storage) (0%)
Lower-case extension for SHA256E and similar. Also, simple way to make sure no big file is ever committed in regular git storage. This is simply too costly to recover from when each copy of a repo is a multi terabyte hard disks with a million+ of files, some in the 10-100kB range, some in the 10-40MB range. (0%)
Speed up transfer of many small files. (0%)
Total votes: 232
git-annex has a community of users, developers, and financial supporters, leading to a rather long list of names on the thanks page. What's your involvement in this community?
none, I just use git-annex (58%)
my name is on the thanks page! (27%)
I rely on the community for tech support and/or file bugs (3%)
Helping other users, filing bugs, pushing git-annex to breaking point (6%)
I try to give feedback where possible (2%)
If I've worked out how to do something with git-annex I sometimes do a write-up in a blog post or similar (0%)
patreon supporter (0%)
Total votes: 231
Do you use git-annex by yourself, or as part of a group of people who share a repository? (If you have multiple repositories, pick the one with the largest group.)
by myself (64%)
by myself so far but I hope to get others using my repository (18%)
1 other person (8%)
2 others (1%)
3-5 others (3%)
6-10 others (1%)
11-25 others (0%)
26-50 others (0%)
50+ others (0%)
Total votes: 228
What kind of data do you mostly use git-annex to store?
personal data (60%)
business data (2%)
scientific data (11%)
game development assets (0%)
rather not say (0%)
cultural archive data (2%)
backups (0%)
podcasts (2%)
video (7%)
Photos (9%)
music (1%)
All active work (0%)
Collected media (0%)
Total votes: 230
There's an additional poll about using git-annex for scientific data.