aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/automatic_conflict_resolution/comment_7_3d2250cc26036b8532faa980065e20d0._comment23
-rw-r--r--doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed/comment_1_0fc5c7251ead7a0fbbcd357a8bc53f05._comment18
-rw-r--r--doc/devblog/day_153__remotedaemon_has_landed/comment_2_fbf0c50f772e958af638d2b72dac73f5._comment10
-rw-r--r--doc/forum/Corrupt_Repository_Invalid_Object/comment_1_b7fd4b6212b50400342931e70684b96c._comment14
-rw-r--r--doc/forum/new_linux_arm_tarball_build/comment_11_859c44046b00fe885f6878cfe0e46360._comment10
-rw-r--r--doc/forum/sync_stages_deletions_on_remote/comment_2_da5775526a2a476b6ead1cd1a735b8bd._comment8
-rw-r--r--doc/tips/using_Amazon_S3/comment_4_92df5a9f923beafba55a1c455728112e._comment13
7 files changed, 96 insertions, 0 deletions
diff --git a/doc/automatic_conflict_resolution/comment_7_3d2250cc26036b8532faa980065e20d0._comment b/doc/automatic_conflict_resolution/comment_7_3d2250cc26036b8532faa980065e20d0._comment
new file mode 100644
index 000000000..9f49021da
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_7_3d2250cc26036b8532faa980065e20d0._comment
@@ -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.
+"""]]
diff --git a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed/comment_1_0fc5c7251ead7a0fbbcd357a8bc53f05._comment b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed/comment_1_0fc5c7251ead7a0fbbcd357a8bc53f05._comment
new file mode 100644
index 000000000..48069eebd
--- /dev/null
+++ b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed/comment_1_0fc5c7251ead7a0fbbcd357a8bc53f05._comment
@@ -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.
+"""]]
diff --git a/doc/devblog/day_153__remotedaemon_has_landed/comment_2_fbf0c50f772e958af638d2b72dac73f5._comment b/doc/devblog/day_153__remotedaemon_has_landed/comment_2_fbf0c50f772e958af638d2b72dac73f5._comment
new file mode 100644
index 000000000..5f81fde5c
--- /dev/null
+++ b/doc/devblog/day_153__remotedaemon_has_landed/comment_2_fbf0c50f772e958af638d2b72dac73f5._comment
@@ -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.
+"""]]
diff --git a/doc/forum/Corrupt_Repository_Invalid_Object/comment_1_b7fd4b6212b50400342931e70684b96c._comment b/doc/forum/Corrupt_Repository_Invalid_Object/comment_1_b7fd4b6212b50400342931e70684b96c._comment
new file mode 100644
index 000000000..a62e6d345
--- /dev/null
+++ b/doc/forum/Corrupt_Repository_Invalid_Object/comment_1_b7fd4b6212b50400342931e70684b96c._comment
@@ -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.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_11_859c44046b00fe885f6878cfe0e46360._comment b/doc/forum/new_linux_arm_tarball_build/comment_11_859c44046b00fe885f6878cfe0e46360._comment
new file mode 100644
index 000000000..7be8a6731
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_11_859c44046b00fe885f6878cfe0e46360._comment
@@ -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..
+"""]]
diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_2_da5775526a2a476b6ead1cd1a735b8bd._comment b/doc/forum/sync_stages_deletions_on_remote/comment_2_da5775526a2a476b6ead1cd1a735b8bd._comment
new file mode 100644
index 000000000..a3076faf7
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote/comment_2_da5775526a2a476b6ead1cd1a735b8bd._comment
@@ -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.
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_4_92df5a9f923beafba55a1c455728112e._comment b/doc/tips/using_Amazon_S3/comment_4_92df5a9f923beafba55a1c455728112e._comment
new file mode 100644
index 000000000..5bcf34b74
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_4_92df5a9f923beafba55a1c455728112e._comment
@@ -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
+
+"""]]