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