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

This commit is contained in:
Joey Hess 2014-04-17 16:12:08 -04:00
commit 6028d34e49
7 changed files with 96 additions and 0 deletions

View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 7"
date="2014-04-17T20:00:22Z"
content="""
@Matthias, here is an example of git-annex merge updating the master branch from the synced/master branch that was pushed to it earlier:
<pre>
joey@darkstar:~/tmp/test/2>git annex merge
merge git-annex (merging synced/git-annex into git-annex...)
ok
merge synced/master
Updating 7942eee..1f3422e
Fast-forward
new_file | 1 +
1 file changed, 1 insertion(+)
create mode 120000 new_file
ok
</pre>
If you are having trouble with it somehow, I'd suggest filing a bug report.
"""]]

View file

@ -0,0 +1,18 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 1"
date="2014-04-17T18:32:40Z"
content="""
(I think you forgot to mention you were using direct mode.)
Like git, git-annex does not preserve file permissions. If you want to ensure that a group or everyone can read file in a git repository, you have to use the core.sharedRepository git configuration. git-annex will also honor that.
git-annex will try to preserve the execute bit, since git does support that single permission bit. But even this cannot be guaranteed. (Eg, when using special remotes which have no concept of file permissions.)
Interrupting rsync and resuming it does cause rsync to not transfer through permissions. This is rsync's normal behavior when not using -p. git-annex used to use rsync -p to preserve whatever file permissions there were. However, <http://bugs.debian.org/700282>, and then [[!commit f92eaf631509d02491c1b0ebfbb15145f80df797]].
It looks like I could preserve the execute bit across interrupt and resume by using rsync's --executability option.
Or, I could use the -p when git-annex is running in a non-crippled filesystem.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 2"
date="2014-04-17T19:31:30Z"
content="""
The daily builds are updated on a daily basis, so already include it.
The release builds are updated on each release, and so do not.
"""]]

View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 1"
date="2014-04-17T19:47:54Z"
content="""
git is complaining about one of the files in `.git/objects` being missing or corrupt.
It's not likely that some accidental command you ran caused this. More likely a disk error or an unclean shutdown could have left the repository in this state.
You can try running `git annex repair` which should be able to repair git repositories with this kind of damage.
Or you can just `git clone` the repository from any other place you have it and move over .git/annex/objects and .git/config to the new repository, discarding the damaged one.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 11"
date="2014-04-17T19:39:41Z"
content="""
I can't see any good way to prevent ld-linux.so from preloading things listed in `/etc/ld.so.preload`. I don't know why raspbian wants to preload that -- probably for optimisation purposes?
I could modify the ld-linux.so shipped in the git-annex tarball, but that way lies pointless complication..
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 2"
date="2014-04-17T19:28:59Z"
content="""
`git annex sync` will push changes to your NAS, but this does not cause the work tree there to be updated. You must be running some command on the NAS that gets it work tree into the state you show. You need to tell us what that command is, since it seems to be where things are going wrong. Maybe you're running the git-annex assistant on the NAS, or maybe you run `git annex sync` on the NAS.
"""]]

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.191"
subject="comment 4"
date="2014-04-17T19:44:55Z"
content="""
You can use `git annex enableremote` to change an existing remote's configuration. So this should work:
# export AWS_ACCESS_KEY_ID=\"newRANDOMGOBBLDEYGOOK\"
# export AWS_SECRET_ACCESS_KEY=\"news3kr1t\"
# git annex enableremote cloud
"""]]