Hello everyone, I would like to know if this is normal behavior or if it's a problem with my repository:
Whenever I set a view with
git annex view attr="*"'
a new branch representing the selected view gets created, as expected. The problem is that when I switch back to master ('git checkout master' or even 'git annex vpop') the view branch stays there, and all subsequent operations on the annex also consider the view branch, resulting a great slowdown if one has done many views (attr="this", attr="that", etc.). Is this normal? If so, why is it necessary for the branch to stay on? Does it speed up going back to the branch? Redoing git annex view attr="*" does not seem to take less time.
Am I doing it wrong? Should I be deleting used view branches on my own? How?
thanks for your replies.
EDIT: I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this?
=== git-annex version: 5.20140529-gb71f9bf ===
You can delete the view branches if you like. I have considered making moving views clean up old branches, but I have also considered reusing existing view branches when popping back to an old view.
git-annex unused can't look at branches that aren't there. Perhaps you have pushed the view branches to a remote repository, and it's checking those branches of the remote? See git branch -a.
I think that it makes sense for unused to ignore (local) view branches, since these are by definition supposed to be views of an existing branch, so looking at the branch should be sufficient (and if the view is out of date and has files that have since been deleted from the branch, the user's intent is not to preserve those from unused reaping). So, made that change.
Alright, I'd very much welcome anyone of the two possibilities as I'm making heavy use of views and would benefit from any of the two solutions.
That's it! Solution for future reference: The remote branches referenced in local repo did not exist anymore in any repo (I had deleted them earlier from the remote) so "git push origin --delete \<branchname>" wouldn't work. This other command worked very well in cleaning up the overwhelming missing remote views all in one go: "git fetch --prune \<remote>"
Thanks a lot! It makes perfect sense, looking forward to it on the next release.
Now, it seems that even after pruning the view branches on the remote, unused would still not collect deleted files. I'm wondering if this is because there are other offline repos (backups which are not practical to take out of their resting place) I have not yet synchronized. I can see their main branches with git branch -a: remotes/oldbackup/git-annex, remotes/oldbackup/master, remotes/oldbackup/synced/git-annex, remotes/oldbackup/synced/master. Does this mean that until all repos (even the offline ones I never sync and work mostly as a backup for old stuff) are synchronized, 'unused' won't collect the deleted files? If so, is there a workaround for this?
Specifically I'm looking for a workaround that would make this behavior possible in this use case:
The user decides some file in the local repository are not needed anymore, they are not needed to be in any repository at all and wants to reclaim the space as soon as possible (or at least make the files available to 'unused' for later removal). Removing the content the from local repository (git-rm ?) the space can be immediately reclaimed in the local hard drive, without the need to connect and sync unavailable/far remotes. As the other remotes and old backups become available and sync, they delete the unused content as well (or at least make it available to 'unused').
Is there a way to achieve this?
git annex drop --force $file; git rm $fileMakes sense in some situations anyway..