Did you change the backend of some files via .gitattributes in the meantime? I think git annex's smudge/clean filter will then return the hash of the new backend and that differs from the one of the old backend, so git reports the files as changed.

There are some details missing here. Did git-annex actually drop the last copy of one of the files? Usually git annex will refuse to do this. What does git annex fsck --fast --quiet say?

I see you patched Git/Hook.hs, but you did not patch Annex/Content/Presence.hs. The Windows builds are still failing.

The semantics described in proposal for timestamp semantics would be all I need to stop wishing I just used rsync instead of git-annex. It seems easier to track history with rsync (snapshots and a CHANGELOG?) than to synchronize timestamps (or xattrs for comments) with git-annex. I don't care if it impacts performance, or if I have to set flags to non-default values, or how it resolves conflicts. I know git doesn't do it natively, but I thought the point of git-annex was to be better than native git with data files. Metadata like this is very useful to me, and often I want to sort by some kind of meaningful timestamp. ls can't read Exif or ID3 tags, and sometimes they aren't available or even relevant.

If I move a symlink up one directory (thus breaking it), git-annex fix "symlink-name" doesn't do anything. the only way I could find to fix it was to do a git annex add $symlink-name. what am I doing wrong?

Finished auditing and fixing anywhere in git-annex this could possibly happen.

To reproduce this, interrupt git-annex after it downloads the whole file, but before it moves it from the download location into the annex. (Or, let it get the file, then move the object back to the temp object location.)

This is a tricky case, because if the total file size is not known when resuming the download, how can it detect if it's got it all already? And git-annex does not always know the total file size, eg when git-annex addurl --relaxed is used, and then git-annex get is later used to download the content.

What git-annex already tried to do to detect this is, when it got a 416 it looks for a Content-Range header "bytes */$size" where $size is the same as the size of the file on disk.

That relied on the http library throwing an exception for the 416. Thing is, http may or may not throw exceptions for non-2xx responses, depending on the input Request. IMHO that is a very bad design, it leads to this kind of bug, rather than making it evident with the data types what is going on.

Currently downloadConduit takes a Request, and assumes it throws exceptions for 416, but not for 401. Both can't be right.

Ok, fixed this mess..

Thanks for reporting. You do not need to worry about this, it seems we accidentially enabled trying to upgrade in the recent release for windows, but git-annex has never actually supported upgrading itself on windows, so of course it fails.

Thanks for that patch, I had been fixing the windows build one line per day, so that sped it up considerably.

I've fixed the issue with the test suite I think, although I will have to wait on tomorrow's windows build to know for sure.

Fixed that. Do note this is not a bug tracker for other software, even if I happen to have written it; you can contact me by email for git-lfs bugs.