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

20 files changed, 393 insertions, 0 deletions

diff --git a/doc/bugs/The_assistant_hangs_forever.mdwn b/doc/bugs/The_assistant_hangs_forever.mdwn
new file mode 100644
index 000000000..604e957c2
--- /dev/null
+++ b/doc/bugs/The_assistant_hangs_forever.mdwn
@@ -0,0 +1,32 @@
+What steps will reproduce the problem?
+
+1. Open the assistant with git-annex webapp
+2. Click add another repository
+3. Choose "add another repository"
+4. Use "/home/pierre/testme" (try and get the problem with a new directory or an existing directory)
+5. Press "Make Repository"
+5. Choose "Keep the repository separate" 
+
+What is the expected output? What do you see instead?
+
+Go to the created repository but the interface hangs forever
+I have 4 git-annex processes that use no CPUs.
+I can still use the UI by clicking around with success or even shutdown the daemon.
+If I shutdown the daemon, all git-annex process gets killed.
+
+What version of git-annex are you using? On what operating system?
+
+It is said to be git-annex version: 4.20130324 but it is actually 4.20130405 (known bug)
+
+Please provide any additional information below.
+
+
+OS: Arch linux, bin package (not installed from source)
+All tests are OK
+Nothing happens on the log pages
+
+This is so weird that I would like to see the log file but I cannot find it. I have looked at /var/log without success.
+I have tried other available version on Arch linux (AUR git-annex-bin, AUR git-annex-standalone, haskell-web git-annex) and they all exhibit the same problem.
+At that stage, what I would like to be able is to try to figure out what is going on using the log file.
+Thanks
+
diff --git a/doc/bugs/The_assistant_hangs_forever/comment_1_b0291e32860e0da0b66837d14ed5aab6._comment b/doc/bugs/The_assistant_hangs_forever/comment_1_b0291e32860e0da0b66837d14ed5aab6._comment
new file mode 100644
index 000000000..b22711b65
--- /dev/null
+++ b/doc/bugs/The_assistant_hangs_forever/comment_1_b0291e32860e0da0b66837d14ed5aab6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://pradermecker.myopenid.com/"
+ ip="81.244.190.181"
+ subject="comment 1"
+ date="2013-04-14T09:45:35Z"
+ content="""
+Forgot to mention that this is my first attempt to work with the assistant on 64 bits (previous binary package were 32 bits only)
+"""]]
diff --git a/doc/bugs/The_assistant_hangs_forever/comment_2_a2950cf91b8a4e4f2951f5522ef0e9c4._comment b/doc/bugs/The_assistant_hangs_forever/comment_2_a2950cf91b8a4e4f2951f5522ef0e9c4._comment
new file mode 100644
index 000000000..90b93f0bb
--- /dev/null
+++ b/doc/bugs/The_assistant_hangs_forever/comment_2_a2950cf91b8a4e4f2951f5522ef0e9c4._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="saironiq"
+ ip="147.251.209.29"
+ subject="comment 2"
+ date="2013-04-14T12:09:11Z"
+ content="""
+Not sure if this is the real reason, but I get a bunch of
+
+>curl: symbol lookup error: /usr/lib/libssl.so.1.0.0: undefined symbol: EVP_idea_cbc
+
+errors in the git-annex log. Running nm on the lib produces the following:
+
+>$ nm /usr/lib/libssl.so.1.0.0 | grep EVP_idea_cbc<br>
+>&nbsp;&nbsp;&nbsp;&nbsp;U EVP_idea_cbc
+
+...where \"U\" means undefined. I think the reason 64-bit does not work is that there is no curl (and lsof) binaries and libs included.
+
+"""]]
diff --git a/doc/bugs/The_assistant_hangs_forever/comment_3_db95f78519d5ffbad793906028730dab._comment b/doc/bugs/The_assistant_hangs_forever/comment_3_db95f78519d5ffbad793906028730dab._comment
new file mode 100644
index 000000000..e9e76f5b2
--- /dev/null
+++ b/doc/bugs/The_assistant_hangs_forever/comment_3_db95f78519d5ffbad793906028730dab._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-14T17:57:47Z"
+ content="""
+The assistant's log file is stored in `.git/annex/daemon.log` within the git repository.
+
+I have to say I don't really understand the bug report. In one sentence you say the \"interface hangs forever\", and then in the next sentence you say you can \"still use the UI by clicking around\". These statements contradict one-another.
+
+(@saironiq, I don't see any connection between what you're saying and pradermecker's bug report. If you have a bug to report, you should file a separate bug report.)
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_10_8305becdc6e70abdaf17e42f263173fc._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_10_8305becdc6e70abdaf17e42f263173fc._comment
new file mode 100644
index 000000000..09c4802f7
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_10_8305becdc6e70abdaf17e42f263173fc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="marvin"
+ ip="91.152.75.65"
+ subject="comment 10"
+ date="2013-04-14T02:34:50Z"
+ content="""
+Hopefully I haven't done anything stupid, wouldn't be the first time :)
+Retried with a different setup, same result.
+Pasted into pastebin as I wasn't sure about the formatting..
+
+<http://pastebin.com/vnnmiBeE>
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_11_d75896a6e204d1abdda04923aa668d04._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_11_d75896a6e204d1abdda04923aa668d04._comment
new file mode 100644
index 000000000..31460ae5b
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_11_d75896a6e204d1abdda04923aa668d04._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 11"
+ date="2013-04-14T02:58:05Z"
+ content="""
+Thanks for that.. It's not verbose enough for me to see it choose the key to use. Can you add one more `v`? ssh -vvv , 3 v's..
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_12_a36a4a64a04c01c2db467b09300e6ebd._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_12_a36a4a64a04c01c2db467b09300e6ebd._comment
new file mode 100644
index 000000000..428d5a43c
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_12_a36a4a64a04c01c2db467b09300e6ebd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="marvin"
+ ip="91.152.75.65"
+ subject="comment 12"
+ date="2013-04-14T09:51:27Z"
+ content="""
+hmm.. I did use -vvv, even tried with 4 which doesen't change anything. Is there a ceartain version of ssh or debian live image I could test with? There shouldn't be anything extraordinary about my setup.
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_13_c9d6631c304acb289e485fb901e1f274._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_13_c9d6631c304acb289e485fb901e1f274._comment
new file mode 100644
index 000000000..083c1e5a2
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_13_c9d6631c304acb289e485fb901e1f274._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 13"
+ date="2013-04-14T18:27:35Z"
+ content="""
+This should not be a hard problem to debug. 
+
+* You have a local client, and a remote server.
+* The remote server has a `~/.ssh/authorized_keys` file that contains a public key that git-annex set up, which is restricted to only run \"command=git-annex-shell\".
+* The local client has that key in `~/.ssh/key.git-annex-$hostname-$username`
+* The local client is configured in `~/.ssh/config` to only use that key when sshing to the special hostname \"git-annex-$hostname-$username\"
+* The problem is either on the client, or on the server.
+* If the problem is on the client, then it must be, somehow, incorrectly sending the git-annex key to the server when you \"ssh $hostname\". You can see what keys it decides to send by looking at the messages it prints with -vvv :
+ 
+<pre>
+joey@gnu:~>ssh -vvv git-annex-kitenet.net-joey
+OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
+debug1: Reading configuration data /home/joey/.ssh/config
+debug1: /home/joey/.ssh/config line 3: Applying options for git-annex-kitenet.net-joey
+debug1: Reading configuration data /etc/ssh/ssh_config
+debug1: /etc/ssh/ssh_config line 19: Applying options for *
+debug2: ssh_connect: needpriv 0
+debug1: Connecting to kitenet.net [80.68.85.49] port 22.
+debug1: Connection established.
+debug3: Incorrect RSA1 identifier
+debug3: Could not load \"/home/joey/.ssh/key.git-annex-kitenet.net-joey\" as a RSA1 public key
+debug1: identity file /home/joey/.ssh/key.git-annex-kitenet.net-joey type 1
+</pre>
+
+* If the problem is on the server, then it must be for some reason deciding to run `git-annex-shell` when you ssh in,
+  despite the client not sending it the special git-annex key. If this were the case, no change you made on the client could fix   
+  the problem, but deleting `.ssh/authorized_keys` on the server probably would.
+
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_14_10282c4352075c8d148b8674973b7b16._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_14_10282c4352075c8d148b8674973b7b16._comment
new file mode 100644
index 000000000..0b1da9029
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_14_10282c4352075c8d148b8674973b7b16._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="ssh agent?"
+ date="2013-04-14T18:34:45Z"
+ content="""
+The only other thing I can think of is that if you have a ssh-agent, it might somehow be caching the git-annex key and incorrectly sending it to ssh. If this were the case, then unsetting `SSH_AUTH_SOCK` or stopping the agent would presumably make the problem go away.
+
+In @marvin's log, I see:
+
+<pre>
+debug1: Offering RSA public key: marvin@marvin-U-100
+</pre>
+
+This is different from what I see when ssh is using a regular key in `.ssh/`:
+
+<pre>
+debug1: Offering RSA public key: /home/joey/.ssh/id_rsa
+</pre>
+
+Marvin's log does not show where it gets this \"marvin@marvin-U-100\".. which makes me suspect it comes from a ssh agent.
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_15_ceb68da01d9e2fe9a70fab6244116da0._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_15_ceb68da01d9e2fe9a70fab6244116da0._comment
new file mode 100644
index 000000000..bbf5a45b5
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_15_ceb68da01d9e2fe9a70fab6244116da0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 15"
+ date="2013-04-14T18:46:54Z"
+ content="""
+I tried the following experiment:
+
+1. Manually ran `ssh-add .ssh/key.git-annex-kitenet.net-joey`
+2. `ssh -vvv kitenet.net` did run git-annex-shell
+
+Guys, please paste the output of `ssh-add -l`
+
+Also, if you run `ssh-add -D`, the problem should go away, and the server should not run git-annex-shell. If that's the case, we've confirmed this is somehow a ssh agent problem. However, I still don't know what could be scanning `~/.ssh` for random keys and loading them into the agent.
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_16_cca4abde86a8be5e2919c4738f5bdd0c._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_16_cca4abde86a8be5e2919c4738f5bdd0c._comment
new file mode 100644
index 000000000..2260917b3
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_16_cca4abde86a8be5e2919c4738f5bdd0c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 16"
+ date="2013-04-14T19:04:11Z"
+ content="""
+Are you guys running Gnome? Using gnome-keyring?
+
+I found the following highly suspicious code inside gnome-keyring:
+
+[[!format C \"\"\"
+        if (!self->directory)
+                self->directory = g_strdup (\"~/.ssh\");
+        self->tracker = gkm_file_tracker_new (self->directory, \"*.pub\", NULL);
+\"\"\"]]
+
+This seems to load *all* keys, as described. Not keys in subdirectories of ~/.ssh/ either.
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_8_1bcb2a238006044bc78849e56cb21a01._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_8_1bcb2a238006044bc78849e56cb21a01._comment
new file mode 100644
index 000000000..9cc054b39
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_8_1bcb2a238006044bc78849e56cb21a01._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="marvin"
+ ip="91.152.75.65"
+ subject="comment 8"
+ date="2013-04-14T00:37:21Z"
+ content="""
+The key in authorized file is the same as git-annex pub key ( key.git-annex-192.168.1.43-marvin.pub )
+Which is also the only ssh key in the authorized file. Is it assumed keys are always used instead of only passwords?
+"""]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_9_26c6937cf78e7141e0e3b20f25ed8f7a._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_9_26c6937cf78e7141e0e3b20f25ed8f7a._comment
new file mode 100644
index 000000000..7f36e3c43
--- /dev/null
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_9_26c6937cf78e7141e0e3b20f25ed8f7a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 9"
+ date="2013-04-14T00:46:32Z"
+ content="""
+Can you please paste the output of `ssh -vvv host
+"""]]
diff --git a/doc/bugs/git_annex_fsck_in_direct_mode_does_not_checksum_files.mdwn b/doc/bugs/git_annex_fsck_in_direct_mode_does_not_checksum_files.mdwn
new file mode 100644
index 000000000..a52a3c4fd
--- /dev/null
+++ b/doc/bugs/git_annex_fsck_in_direct_mode_does_not_checksum_files.mdwn
@@ -0,0 +1,17 @@
+What steps will reproduce the problem?
+
+Put some large files into a direct mode repository (so fsck time is noticeable).  git annex add them, commit, run git annex fsck.
+
+What is the expected output? What do you see instead?
+
+Expected: files are checksummed, which should take considerable amount of time for each file.  For reference, in indirect mode, fsck takes a while for files of ~1GB size.
+Actually: in direct mode, git annex fsck goes through all of the files in an instant and prints OK for each. I believe the file content is not verified.
+Multiple runs of git annex fsck do the same thing.
+
+What version of git-annex are you using? On what operating system?
+
+git-annex version: 4.20130405, Linux
+
+Please provide any additional information below.
+
+
diff --git a/doc/bugs/git_annex_fsck_in_direct_mode_does_not_checksum_files/comment_1_a6cde4aa495512344fa7f50e10749c68._comment b/doc/bugs/git_annex_fsck_in_direct_mode_does_not_checksum_files/comment_1_a6cde4aa495512344fa7f50e10749c68._comment
new file mode 100644
index 000000000..5aaebc342
--- /dev/null
+++ b/doc/bugs/git_annex_fsck_in_direct_mode_does_not_checksum_files/comment_1_a6cde4aa495512344fa7f50e10749c68._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-14T17:50:53Z"
+ content="""
+This is expected. The content of direct mode files can change at any time, so fsck does not have a locked down object with a known checksum that it can verify. Similarly, fsck skips unlocked files in indirect mode.
+"""]]
diff --git a/doc/design/assistant/blog/day_235__birthday/comment_5_73aad3398a43bc4d28bca9bf635fa757._comment b/doc/design/assistant/blog/day_235__birthday/comment_5_73aad3398a43bc4d28bca9bf635fa757._comment
new file mode 100644
index 000000000..969253971
--- /dev/null
+++ b/doc/design/assistant/blog/day_235__birthday/comment_5_73aad3398a43bc4d28bca9bf635fa757._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.48.75.171"
+ subject="Just in case it might be helpful..."
+ date="2013-04-14T05:56:47Z"
+ content="""
+For whatever reason, dragging links onto the page text in the \"Using drag and drop for selecting\" section of <http://www.html5rocks.com/en/tutorials/file/dndfiles/#toc-selecting-files-dnd> does not trigger the usual page change. I don't really know why--I couldn't get it to work on my own with Firebug. And thanks for git-annex--love it!
+"""]]
diff --git a/doc/forum/Direct_special_remotes/comment_4_187036bbfee0508e2914afb51ead3c71._comment b/doc/forum/Direct_special_remotes/comment_4_187036bbfee0508e2914afb51ead3c71._comment
new file mode 100644
index 000000000..1f6287111
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_4_187036bbfee0508e2914afb51ead3c71._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://pradermecker.myopenid.com/"
+ ip="81.244.190.181"
+ subject="comment 4"
+ date="2013-04-14T09:01:27Z"
+ content="""
+Thanks !
+
+Before trying the CLI, I will install have a go with installing git-annex on the plug computer.
+
+Do you know by any chance if version 3.20120629~bpo60+2 (the available version on squeeze-backport) will be compatible with the current latest release (4.20130405) ?
+
+I guess I am asking if version 3 is compatible with version 4.
+
+
+"""]]
diff --git a/doc/forum/Direct_special_remotes/comment_4_6bfbf60f2061d49b7d34c844e7e1dea2._comment b/doc/forum/Direct_special_remotes/comment_4_6bfbf60f2061d49b7d34c844e7e1dea2._comment
new file mode 100644
index 000000000..86621a00e
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_4_6bfbf60f2061d49b7d34c844e7e1dea2._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.48.75.171"
+ subject="comment 4"
+ date="2013-04-14T01:07:19Z"
+ content="""
+@pradermecker: I think that the CLI would be able to do what you're describing (to some extent), but the issue is that the filenames it creates will be hashes, and not in the folder pattern that is on your laptop. Of course, if the plug computer uses file metadata to determine file info, and will search a directory tree, then it probably won't care that the files are named strange things.
+
+As a quick example:
+
+I have a repo with three files in it:
+
+    $ ls -R
+    .:
+    File 1  File 2  File 3
+
+I copy those files to a directory remote:
+
+    $ git annex copy --to=test-dir *
+    copy File 1 (to test-dir...) 
+    ok                      
+    copy File 2 (to test-dir...) 
+    ok                      
+    copy File 3 (to test-dir...) 
+    ok                      
+    (Recording state in git...)
+
+Then I look at what's in my directory remote:
+
+    $ cd ../remote
+    $ ls -R
+    .:
+    0d4  d35  f15
+
+    ./0d4:
+    d37
+
+    ./0d4/d37:
+    SHA256-s7--a940d8aadc02f798331b2d46f1a8ad2c9821783060f4a0810da42bf785855c1c
+
+    ./0d4/d37/SHA256-s7--a940d8aadc02f798331b2d46f1a8ad2c9821783060f4a0810da42bf785855c1c:
+    SHA256-s7--a940d8aadc02f798331b2d46f1a8ad2c9821783060f4a0810da42bf785855c1c
+
+    ./d35:
+    55c
+
+    ./d35/55c:
+    SHA256-s7--ab1ad6a49c022416008887464b8dc03b523b9e81530cf47d1f6f7712c1b30955
+
+    ./d35/55c/SHA256-s7--ab1ad6a49c022416008887464b8dc03b523b9e81530cf47d1f6f7712c1b30955:
+    SHA256-s7--ab1ad6a49c022416008887464b8dc03b523b9e81530cf47d1f6f7712c1b30955
+
+    ./f15:
+    3f2
+
+    ./f15/3f2:
+    SHA256-s7--d1993f1115215aa6389e33fa9979fb39bb29e5bed14661baf1cf6af3182f0164
+
+    ./f15/3f2/SHA256-s7--d1993f1115215aa6389e33fa9979fb39bb29e5bed14661baf1cf6af3182f0164:
+    SHA256-s7--d1993f1115215aa6389e33fa9979fb39bb29e5bed14661baf1cf6af3182f0164
+
+I haven't checked, but I think that the assistant will be able to use a special remote that you create from the CLI once you create it.
+
+To create a remote without encryption using the CLI, try a command of the form `git annex initremote remote-name blah blah blah encryption=none`
+Also see the information at [[special_remotes/directory]], [[special_remotes/rsync]], and [[Repo accessible from \"dumb\" client without git-annex]].
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_3_a1cf93f9b29658f0f26e9e0ae6057ee3._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_3_a1cf93f9b29658f0f26e9e0ae6057ee3._comment
new file mode 100644
index 000000000..91122360a
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_3_a1cf93f9b29658f0f26e9e0ae6057ee3._comment
@@ -0,0 +1,60 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="Trying this feature"
+ date="2013-04-14T13:04:55Z"
+ content="""
+I just gave this feature a try, but it seems it doesn't work as expected or maybe I don't understand it:
+
+    ~/annex/largefilestest % git init
+    ~/annex/largefilestest (git)-[master] % git annex init \"test repo\"
+    ~/annex/largefilestest (git)-[master] % git config annex.largefiles \"not include=*.txt\"
+
+Now I copy two files to this directory and add both to the annex
+
+    ~/annex/largefilestest (git)-[master] % ll
+    total 100
+    -rw-rw-r-- 1 tobru tobru 93709 Oct 19 16:14 dpkg-get-selections.txt
+    -rw-rw-r-- 1 tobru tobru  7256 Jan  6 15:52 x3400.jpg
+    ~/annex/largefilestest (git)-[master] % git annex add .
+    add x3400.jpg (checksum...) ok
+    (Recording state in git...)
+    ~/annex/largefilestest (git)-[master] % git status
+    # On branch master
+    #
+    # Initial commit
+    #
+    # Changes to be committed:
+    #   (use \"git rm --cached <file>...\" to unstage)
+    #
+    #       new file:   x3400.jpg
+    #
+    # Untracked files:
+    #   (use \"git add <file>...\" to include in what will be committed)
+    #
+    #       dpkg-get-selections.txt
+    ~/annex/largefilestest (git)-[master] % ll
+    total 96
+    -rw-rw-r-- 1 tobru tobru 93709 Oct 19 16:14 dpkg-get-selections.txt
+    lrwxrwxrwx 1 tobru tobru   192 Jan  6 15:52 x3400.jpg -> .git/annex/objects/vf/QX/SHA256E-s7256--60e5b69ade5619e37f7fcaa964626da9c415959d861241aa13e2516fffc2dddf.jpg/SHA256E-s7256--60e5b69ade5619e37f7fcaa964626da9c415959d861241aa13e2516fffc2dddf.jpg
+
+So the picture is added to the annex as expected. But the .txt file is not added to git. Do I have to manually add this to git? And why is the picture seen as new file by git?
+
+The second question could be answered by: \"run git annex sync\". Is this correct? Because after running this command, git does not see this file as a new file anymore:
+
+    ~/annex/largefilestest (git)-[master] % git annex sync
+    commit  
+    [master (root-commit) a0afb14] git-annex automatic sync
+     1 file changed, 1 insertion(+)
+     create mode 120000 x3400.jpg
+    ok
+    git-annex: no branch is checked out
+    ~/annex/largefilestest (git)-[master] % git status
+    # On branch master
+    # Untracked files:
+    #   (use \"git add <file>...\" to include in what will be committed)
+    #
+    #       dpkg-get-selections.txt
+    nothing added to commit but untracked files present (use \"git add\" to track)
+
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_4_e10671908b58c554375787d0f76e2366._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_4_e10671908b58c554375787d0f76e2366._comment
new file mode 100644
index 000000000..14a909014
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_4_e10671908b58c554375787d0f76e2366._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-04-14T18:37:50Z"
+ content="""
+Like it says in the tip, `git annex add` will add the large files to git. You can add the small files with `git add`; git-annex won't do that for you. 
+
+To automatically add both sorts of files, you can use the `git annex watch` or `git annex assistant` daemons. The latter also keeps files in sync between repositories automatically.
+
+(Why did the picture show up as a new file in git? Because you hadn't committed it. This is the same as when you `git add` a file;
+it's only staged in the index; `git status` will show it is new until you `git commit`)
+"""]]