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 2014-10-06 11:48:11 -04:00
commit a551add868
7 changed files with 98 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

10
doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 1"
date="2014-10-06T15:11:18Z"
content="""
There might be a general problem with using git-annex against a read-only filesystem, but the specific case here is a read-only filesystem containing a repository in an old format which git-annex needs to upgrade to the current format to use. So it's pretty reasonable that the (automatic) upgrade fails, since it's not being allowed to write to the repository to upgrade it.
Now, if that repository is a indirect mode repo, there is really no change between version 3 and version 5, so it might do to let git-annex ignore the failure to write out the config, and treat that repo as if it's a v5 repo. It seems easier in most cases to mount the media read-write for git-annex to do the upgrade though.
"""]]

8
doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://id.koumbit.net/anarcat"
ip="72.0.72.144"
subject="comment 2"
date="2014-10-06T15:18:20Z"
content="""
i've seen problems like this not related to upgrades at all, in [[todo/read-only removable drives]]. furthermore, it seems to me that failure to upgrade a repository shouldn't be fatal and we should be able to recover and get files anyways, in the spirit of [[backwards compatibility|future_proofing]]. --[[anarcat]]
"""]]

10
doc/bugs/git_clone_ignores_annex/comment_1_18ba05c51f82ddadd2558f6cd789e394._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 1"
date="2014-10-06T15:42:26Z"
content="""
Making that symlink is extremely unsafe! git-annex will see two repositories. So if a file is present in the annex, with only one actual copy existing, and you try to drop it, git-annex will go check the other repository, find the file there, assume this means there's an extra copy and so proceed with the drop. Which deletes the only existing copy of your file. So if you do this, you will likely eventually lose data.
However, recent versions of git-annex will detect if you clone a git repository with `--shared` and automatically hard link files into the annex when getting them into that repository. They also mark the shared clone as untrusted, to avoid the above problem. This is a much better solution.
"""]]

16
doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_1_875ca12936d4b4505f2e280a454fe558._comment Normal file
View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.54"
subject="comment 1"
date="2014-10-06T15:47:39Z"
content="""
I am unable to reproduce any problem with the steps you gave. I don't see any typechange message, and would not expect one. Perhaps your repository is lacking a .git/hooks/pre-commit script to run git-annex when you use `git commit -a`?
It's not clear to me what problem you experienced, beyond the typechange message that I don't see.
> git unlock test.txt (corrects and retains both versions)
I don't understand that line at all. `git unlock` is not a valid git command, and what does \"corrects and retains both versions\" mean?
Please provide an actual trascript of the problem, rather than the unclear description.
"""]]