The principle idea of git-annex is to track big file content outside of git by putting symbolic links inside of git repositories instead of the content. This idea works well under Linux and MacOS, but not at all under Windows. Windows file systems historically do not really support symbolic linking (and are called crippled file systems by the annex developers subsequently).
Furthermore, Windows file path length is limited to 256 characters, meaning that you only have that many characters until a file path is simply too long. A typical file path to a naively created annex file under Windows looks something like the following:
C:\user\docs\myrepo\.git\annex\objects\X9\W1\SHA256E-s55794550--6f10563e40e589ca906a4d5049fb8b38c28654049fb71683e31a0d3bc518d64d.jpg\SHA256E-s55794550--6f10563e40e589ca906a4d5049fb8b38c28654049fb71683e31a0d3bc518d64d.jpg
Where just the pure annex path is nearly 200 chars long (leaving only ~50 for the directory path). It's not hard to see how this can become a problem.
An easy way around that is to use the so-called md5 backend of annex instead of the default sha256 one which cuts the annex path length to roughly 120 characters. This needs a rather up to date version of annex however (especially not the one from the Ubuntu 14.04 repositories - consider using this).
Using md5 and also working around the linking issues is something that the client tries to make easy for you. However, we want to raise awareness towards the underlying issues here, especially to give direct users of annex a helping hand.
So, if you want to use annex directly and if you want to use that data under Windows with annex, be sure to use md5 backend, consider annex direct mode, and generally take care. In the worst case, people will still be able to download data from the web interface directly.
This will delete the page "Some Notes On Git Annex". Please be certain.