OS X: 10.11.6 Annex: git-annex-6.20160619 (via brew)
I'm still strugling with my annex repo over here. My problem is that for some reason git annex wants to repair my repo all the time when I'm starting the assistant and this (seemingly) never finishes, so I'm caught in an infinite loop in which no files get uploaded to my various remotes and nothing is downloaded either leaving me with all the data on my hard drive and nothing else. I would like to move on. How can I recover from this state? The daemon.log file doesn't show any information about what is happening during the repair and what might cause the failure. Is there another log file I could look at?
Any help is appreciated at that point. Where should I look for more information? What should I do to change the behaviour? I want to solve this once and for all.
I don't use the assistant myself, so I may not be much help.
Have you tried opening the terminal and running
it may yield more information about what's wrong.
You may want to also try
as well.
Thanks you so much for the suggestions! I tried running
git annex fsckwhich yielded no errors and also rangit fsckwhich gave the following output:I'm now running git annex repair through the command line and hoping for the best. I'm sure this will run for a while. The output so far is just
Running git fsck ...but I can see it's doing something since the terminal application in osx shows what commands it's currently running in the header of the window itself. I'm hoping this repair will finnish until tomorrow morning because I have a flight coming up at 8. Let's see.Unfortunately, I'm not familiar with the errors that git fsck is giving you, so I should defer to someone who knows more. I don't want to tell you something that makes the problem worse
If repairing doesn't work, one other thing you could try is cloning the repository that's giving you trouble, and using git annex to move the data into the new clone. This won't modify your original (defective) repository.
If you have files in your original repository that the assistant hasn't committed yet, they won't be in the new clone. So you should look around in /path/to/newClone to see if everything is there. You can run
to see any files that have not yet been committed in the defective repository, and copy them over manually.
Good luck! Hope you get it working.
Very interesting git fsck output!
It seems like your git repository has somehow gotten a tree object in it which contains two files with the same name.
While git's data structures allow this, it's pretty nonsensical, and it's not something that would normally ever happen. It would be interesting to take a look and see what commits use those tree objects, and where those strange trees came from.
git-annex in turn is seeing that tree object's sha in the fsck output and assumes fsck means that the data for that object is broken or missing. So, I suppose what I'll do is make it skip over lines containing
duplicateEntries, and then it won't try to repair this repository.Another user reported the same problem. Their repo indeed had a tree object that contained two items with the same name. In this case, two trees, with different contents.
This user had been using adjusted branches, which would be my lead suspect.
Original reporter, did you use git-annex's adjusted branches feature.
Not that I know of. I tried a whole bunch of things, like deleting remotes, killing processes trying to switch between repo versions, modes, playing around in config files etc. etc. Not all of them were smart ideas, I admit. At some point it worked and if I remember correctly I tried to delete a branch and then the problems started. But adjusted branches seems to me like a too advanced feature to use.
Btw.: Skipping over these entries doesn't help for me. It still tries to repair the repo (which takes maybe 4 hours, including having to initiate a temporary repo).
This is not correct. I tried to delete a special remote.
The first try at making git-annex ignore the fsck lines about duplicate entries didn't quite work; the second try landed 8 days ago and it's not been in a release yet so that's probably why you continue to see the problem.
I don't see how deleting a special remote could lead to this. But we know that
git annex adjust --unlockdid, for another user.