mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2013-01-08 15:09:38 -04:00
commit f1942a2859
3 changed files with 42 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
doc/bugs/drop_fails_to_see_copies_that_whereis_sees/comment_1_f5a9d99d90daf5eba4773d361fa1807a._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.211"
subject="comment 1"
date="2013-01-08T18:43:33Z"
content="""
So, the first part of this is git-annex behaving as designed. When there's a fatal disk problem and it cannot update its local location log, only the remote's location log gets updated. After a `git annex sync` (or your manual equivilant), the location log changes get propigated from the remote, and the local repository returns to a consistent state.
As to the drop problem, look at it again. You have numcopies configured to 2, and there are currently 2 copies of the file. So dropping 1 would leave the numcopies constraint unsatisfied, and so it doesn't. You can override --numcopies 1 or --force the drop, but I don't see a bug here.
(Perhaps the \"No other repository is known to contain the file.\" message is confusing in this context? It doesn't mean that no other repo has the file at all, but that there are no other repositories, that it was not able to check, that might have the file. If you had another removable drive with the file, and the drive was detached, this message would instead say \"Try making some of these repositories available: otherdrive\")
(Re fscking in a bare repo, in a bare repository, you cannot fsck specific files/directories; fsck just checks every single key that git-annex knows about.)
"""]]

15
doc/bugs/renaming_a_file_makes_annex_get_the_file__39__s_content_from_remote/comment_1_d6aad1831674586fe4cdf61dd2a4bbb9._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.211"
subject="comment 1"
date="2013-01-08T18:35:58Z"
content="""
Since your local repository is in the client group, this behavior is actually as intended. Client group means the [[preferred_content]] settings will try to get the content of all files, unlless they're in a directory named \"archive\". This happens not just when you rename a dropped file, but on startup, when the network comes up, or even just periodically it'll notice if some file's content is missing and download it.
So, your choices are
1. Make an `archive` directory, and move files into it when you don't want them available locally. The assistant will even automatically drop them when you move them.
2. Use `git annex vicfg` to set up your own [[preferred content]] expression that makes it behave how you want. For example, you could use `present` to make the assistant not prefer to have the content of files, unless the content is already present, and then manually `git annex get` and `git annex drop` files as desired.
(BTW, you can use \"drop\" in direct mode with yesterday's release.)
"""]]

13
doc/news/version_3.20130102/comment_4_16cd8e889dc91b456e08df4eb9856c15._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.211"
subject="comment 4"
date="2013-01-08T18:30:00Z"
content="""
The 3.20130107 release declares tighter versioned dependencies on yesod stuff, which should fix that.
---
I am at a loss about the error message you showed. It seems to have something to do with gpg signed data
being present in the git-annex branch of your repository, but git-annex doesn't do that. I think you need to either file a [[bug|bugs]] report with more information, and/or email me your repository so I can investigate what's going on with it to make this happen. (joey@kitenet.net)
"""]]