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

7 files changed, 159 insertions, 0 deletions

diff --git a/doc/bugs/fatal:_Out_of_memory__63___mmap_failed:_No_error/comment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment b/doc/bugs/fatal:_Out_of_memory__63___mmap_failed:_No_error/comment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment
new file mode 100644
index 000000000..bf120c20a
--- /dev/null
+++ b/doc/bugs/fatal:_Out_of_memory__63___mmap_failed:_No_error/comment_1_3bc14a8b093ebb2c0571f5a554ef8cf3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 1"
+ date="2014-04-17T17:25:29Z"
+ content="""
+That error message is a git error message (from git's `wrapper.c`), not a git-annex error message.
+
+It's quite possible that git does not scale to as many file on Windows as it does on Unix, and git is known to not scale particularly well to vast numbers of files even on unix, although running out of memory is not the typical failure mode there.
+
+I think you should file a bug report on git.
+"""]]
diff --git a/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn
new file mode 100644
index 000000000..2dfd69440
--- /dev/null
+++ b/doc/bugs/git-annex_clears_files__39___og+r_permissions_when_rsync_transfer_is_interrupted_and_resumed.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+umask is 022 on both hosts
+If one does ls -lL on source repo, the files are shown 644.
+
+Now, "git annex get" from a clone done over ssh generally preserves 644 ... except if the transfer (rsync) is interrupted, and then resumed.
+In fact, looks like the temp files in .git/annex/tmp have the og+r bits cleared during the resumed transfer.
+
+So this is inconsistent: I don't see why permissions should be different, depending whether or not there was an interruption in the transfer.
+Plus, og+r permissions can actually be important for setups like serving contents using Samba.
+
+### What steps will reproduce the problem?
+
+    cd dir1
+    git init
+    git annex init
+    touch a
+    truncate -s 10G b
+    git annex add .
+    git commit -m 'new'
+
+    git clone localhost:/path/to/dir1 dir2
+    cd dir2
+    git annex get
+    ctrl^c
+    git annex get
+    ls -lL
+    ... see different perms
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20140411-gda795e0
+Linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment b/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment
new file mode 100644
index 000000000..5ff090ffd
--- /dev/null
+++ b/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo"
+ nickname="Georg"
+ subject=" remotedaemon in pre-built tarballs"
+ date="2014-04-17T07:40:25Z"
+ content="""
+Hi Joey,
+
+can you tell me when the pre-built Linux tarballs will include the remotedaemon?
+Are they updated on a daily basis?
+
+Best regards, Georg
+"""]]
diff --git a/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment b/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment
new file mode 100644
index 000000000..063260ba1
--- /dev/null
+++ b/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="Claes"
+ subject="comment 3"
+ date="2014-04-17T14:04:31Z"
+ content="""
+Yeah, git does not have the concept of checking out subdirectories that subversion does. You could, however, have different branches with different content that live in the same repo and therefore share the same git-annex backend, so there could be overlap between what files are in what branch without them using up much extra disk space.
+"""]]
diff --git a/doc/forum/sync_stages_deletions_on_remote.mdwn b/doc/forum/sync_stages_deletions_on_remote.mdwn
new file mode 100644
index 000000000..73a51d0b0
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote.mdwn
@@ -0,0 +1,72 @@
+I'm having an issue with 2 repos: one on my laptop, the other on my NAS. Both are in indirect mode, running Arch Linux, and have the latest Git version. Laptop has git-annex 5.20140411-gda795e0, NAS has 5.20140319-g9aa31b7 (from prebuilt tarballs).
+
+The issue is quite simple. When I `git-annex add` new files on my laptop, commit them, and then `git-annex sync` them, they show up as staged for deletion on my NAS.
+
+    laptop $ git annex add some-file
+    laptop $ git commit -m "Add some-file"
+    laptop $ git annex sync
+    commit  ok
+    pull ds413j 
+    ok
+    push ds413j 
+    Counting objects: 133, done.
+    Delta compression using up to 8 threads.
+    Compressing objects: 100% (78/78), done.
+    Writing objects: 100% (80/80), 10.64 KiB | 0 bytes/s, done.
+    Total 80 (delta 12), reused 0 (delta 0)
+    To ssh://**/**
+       1dcd188..8ef4249  git-annex -> synced/git-annex
+       c0f45a6..21711d6  master -> synced/master
+    ok
+    laptop $ ssh $NAS
+    nas $ git status
+    On branch master
+    Changes to be committed:
+      (use "git reset HEAD <file>..." to unstage)
+
+            deleted:    some-file
+
+    nas $
+
+If I run `git annex sync` on the NAS, it will create a new commit that deletes that file. So I have to play with `git reset`/`git checkout` by hand to make sure that the new file won't be deleted.
+
+I'm not sure when this started, but I think it was after I did some stupid mistake (`git checkout -B master synced/master`, kill a `git annex sync` with Ctrl+C, or something else that even resulted in my non-bare repo to have "bare=true" in .git/config...). And I haven't yet been able to fix this.
+
+Any idea what can have caused this, how to fix it, and how to prevent it from happening again in the future?
+
+.git/config on NAS:
+
+    [core]
+            repositoryformatversion = 0
+            filemode = true
+            logallrefupdates = true
+    [annex]
+            uuid = d54ae60a-1f59-403c-923f-32ea3bf2d00f
+            version = 5
+            diskreserve = 1 megabyte
+            autoupgrade = ask
+            debug = false
+
+.git/config on laptop:
+
+    [core]
+            repositoryformatversion = 0
+            filemode = true
+            bare = false
+            logallrefupdates = true
+    [branch "master"]
+    [annex]
+            uuid = f20cb506-945d-4c78-af1a-0aa884bb899b
+            version = 5
+            diskreserve = 20 gigabytes
+            autoupgrade = ask
+            debug = false
+            expireunused = 7d
+            genmetadata = true
+    [push]
+            default = matching
+    [remote "ds413j"]
+            url = ssh://**/**
+            fetch = +refs/heads/*:refs/remotes/ds413j/*
+            annex-uuid = d54ae60a-1f59-403c-923f-32ea3bf2d00f
+            annex-sync = true
diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment b/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment
new file mode 100644
index 000000000..24495fd02
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ subject="comment 1"
+ date="2014-04-17T12:16:41Z"
+ content="""
+Here's the output of `git annex sync --debug` (for a different commit): <http://ix.io/bJZ>
+"""]]
diff --git a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn b/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn
new file mode 100644
index 000000000..00f500d10
--- /dev/null
+++ b/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn
@@ -0,0 +1 @@
+One problem I keep having when using a direct repo is that in order to get to the previous versions of a file you have to convert that repo to indirect and then checkout previous commits this becomes problematic when the repo in question is large conversion takes a long time and applications gets confused if there are open files from the repo as they go from actual files to symlinks. Is it possible to have a separate annex command that will checkout a previous version of a file to a different directory so we can replace/inspect it.