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

17 files changed, 171 insertions, 0 deletions

diff --git a/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo/comment_1_88fbf70eae48484988dbb433a437c717._comment b/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo/comment_1_88fbf70eae48484988dbb433a437c717._comment
new file mode 100644
index 000000000..84686f1e4
--- /dev/null
+++ b/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo/comment_1_88fbf70eae48484988dbb433a437c717._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T18:20:05Z"
+ content="""
+It's true that deleting a ssh repository in the webapp does not delete any ssh keys that the webapp configured to access that repository. I'm a bit reluctant to try to clean it up entirely automatically, because the ssh configuration might have been manually altered, or might be used by another local repository. Particularly, if another local repo is set up to use the same ssh remote, the webapp will reuse the ssh key.
+
+> Create, delete and create again a new repo on remote ssh server with password auth.
+
+I tried doing this, and did not encounter any problem. Since the new repo had a different path on the ssh server, I simply ended up with two ssh keys configured in `~/.ssh/config` for two different repositories. The presence or absence of the first key did not affect the second key.
+
+I think you need to go into more detail about exactly what you did, or show the files in .ssh that were set up, so I can see what the actual problem is.
+"""]]
diff --git a/doc/bugs/Hanging_on_install_on_Mountain_lion/comment_5_2a336fe7b8aed07cbdaa868bd34078f9._comment b/doc/bugs/Hanging_on_install_on_Mountain_lion/comment_5_2a336fe7b8aed07cbdaa868bd34078f9._comment
new file mode 100644
index 000000000..aceafcf9f
--- /dev/null
+++ b/doc/bugs/Hanging_on_install_on_Mountain_lion/comment_5_2a336fe7b8aed07cbdaa868bd34078f9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 5"
+ date="2013-06-25T17:14:02Z"
+ content="""
+To get this fixed, someone is going to need to do some investigation of what is happening. I do not have resources to debug OSX problems that cannot be reproduced using the command line.
+"""]]
diff --git a/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_1_8229df64a872bee7590f75eb78f78c4a._comment b/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_1_8229df64a872bee7590f75eb78f78c4a._comment
new file mode 100644
index 000000000..26881f17b
--- /dev/null
+++ b/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_1_8229df64a872bee7590f75eb78f78c4a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T18:08:55Z"
+ content="""
+As far as I know, there have been no changes to the local pairing protocol that would cause a problem like this. 3.20121112 is a few months after local pairing was first developed.
+
+Have you tried upgrading and re-pairing?
+"""]]
diff --git a/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_2_f37be896396915b1c85cff8811dceb4a._comment b/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_2_f37be896396915b1c85cff8811dceb4a._comment
new file mode 100644
index 000000000..d9ad17e79
--- /dev/null
+++ b/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_2_f37be896396915b1c85cff8811dceb4a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm01ida6POv7vqyUYtOlymEbJTbrImAIzM"
+ nickname="Reinis"
+ subject="comment 2"
+ date="2013-06-25T18:50:00Z"
+ content="""
+I have not tried to upgrade, but I fixed it using annex describe followed by assistant restart as hinted in /usr/share/doc/git-annex/html/bugs/uuid.log_trust.log_and_remote.log_merge_wackiness.html.
+
+From that document I understood that at worst it should use one of the two uuids (from Ubuntu or Gentoo repo), but it should not leave it without uuid and hence this report.
+
+I have tried it a couple of times and it is perfectly reproducible.
+"""]]
diff --git a/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_3_df7fc1078059538a76f384a40541e91f._comment b/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_3_df7fc1078059538a76f384a40541e91f._comment
new file mode 100644
index 000000000..75fd81d46
--- /dev/null
+++ b/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_3_df7fc1078059538a76f384a40541e91f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 3"
+ date="2013-06-25T19:13:06Z"
+ content="""
+An old bug report that was fixed in 2011 seems very unlikely to have anything to do with your local pairing problem.
+
+Why don't you try upgrading?
+"""]]
diff --git a/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_4_70c444c61f41df2f59294c10f94f0c09._comment b/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_4_70c444c61f41df2f59294c10f94f0c09._comment
new file mode 100644
index 000000000..8e895be5f
--- /dev/null
+++ b/doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_4_70c444c61f41df2f59294c10f94f0c09._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm01ida6POv7vqyUYtOlymEbJTbrImAIzM"
+ nickname="Reinis"
+ subject="comment 4"
+ date="2013-06-25T19:34:12Z"
+ content="""
+I was expecting the version in distribution which came out two months ago to be somewhat recent, probably unfounded expectation for non-rolling release distribution. I'll add PPA and try using that one.
+"""]]
diff --git a/doc/bugs/Problems_with_syncing_gnucash/comment_1_ca195af3ba4a286eb5ab687634192fa4._comment b/doc/bugs/Problems_with_syncing_gnucash/comment_1_ca195af3ba4a286eb5ab687634192fa4._comment
new file mode 100644
index 000000000..481f65d5b
--- /dev/null
+++ b/doc/bugs/Problems_with_syncing_gnucash/comment_1_ca195af3ba4a286eb5ab687634192fa4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T17:30:05Z"
+ content="""
+First of all, are you sure that git-annex is even the right tool for this job? gnucash files tend to be pretty small, and are easy to check into git directly. What happens if two machines make conflicting edits, and the git-annex assistant automatically resolves the merge conflict by moving files around and making .variant copies of gnucash log files?
+"""]]
diff --git a/doc/bugs/Problems_with_syncing_gnucash/comment_2_754fb430381ad88e6248ecb902b32118._comment b/doc/bugs/Problems_with_syncing_gnucash/comment_2_754fb430381ad88e6248ecb902b32118._comment
new file mode 100644
index 000000000..ff81b4d98
--- /dev/null
+++ b/doc/bugs/Problems_with_syncing_gnucash/comment_2_754fb430381ad88e6248ecb902b32118._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 2"
+ date="2013-06-25T17:49:08Z"
+ content="""
+I was able to reproduce this with gnucash, and came up with a small test case:
+
+[[!format perl \"\"\"
+my $foo=\"foo\";
+open(OUT, \">$foo.new\");
+link(\"$foo.new\", \"$foo\");
+unlink(\"$foo.new\");
+close OUT;
+\"\"\"]]
+
+This defeats the watcher, which sees the file be opened for write, and then deleted before it's closed. To fix this it would need to correlate the hard link with the original file, to know that when the original file is closed, the hard link can now be safely added to the annex.
+
+The daily sanity checker will find and eventually add these files, or the assistant will see them the next time it's started.
+"""]]
diff --git a/doc/design/assistant/blog/day_267__windows_autobuilder/comment_2_8f978d2811c8fbf11e3d12f245bdb52b._comment b/doc/design/assistant/blog/day_267__windows_autobuilder/comment_2_8f978d2811c8fbf11e3d12f245bdb52b._comment
new file mode 100644
index 000000000..796dea21e
--- /dev/null
+++ b/doc/design/assistant/blog/day_267__windows_autobuilder/comment_2_8f978d2811c8fbf11e3d12f245bdb52b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 2"
+ date="2013-06-25T17:12:17Z"
+ content="""
+That is the same problem that is currently making the test suite fail on the windows autobuilder.
+
+I don't know what is causing this problem, and have not been able to reproduce it locally in order to debug it.
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_9_fbb9eba65fbb72201f08511945fbcf8c._comment b/doc/forum/XMPP_authentication_failure/comment_9_fbb9eba65fbb72201f08511945fbcf8c._comment
new file mode 100644
index 000000000..e019056de
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_9_fbb9eba65fbb72201f08511945fbcf8c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 9"
+ date="2013-06-25T17:18:56Z"
+ content="""
+Boris, that seems like an unrelated problem to the one affecting ejabberd. Different error message. 
+
+"""]]
diff --git a/doc/forum/endless_password_prompt_loop/comment_1_cceba12ed25cd671c7cee5a28631163e._comment b/doc/forum/endless_password_prompt_loop/comment_1_cceba12ed25cd671c7cee5a28631163e._comment
new file mode 100644
index 000000000..d162ff3e5
--- /dev/null
+++ b/doc/forum/endless_password_prompt_loop/comment_1_cceba12ed25cd671c7cee5a28631163e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T19:49:25Z"
+ content="""
+What version of git-annex? Did more than one password prompt window somehow appear at the same time? What is doing the ssh password prompting, is it ssh-askpass, or something provided by your desktop environment?
+
+What happens if you manually ssh from your computer to the NAS, using the special hostname that git-annex has configured (you can find this hostname in the `.git/config`). `ssh -v` is generally a good way to track these problems down.
+"""]]
diff --git a/doc/forum/git-annex_teams___47___groups/comment_1_0450673ab74f184a47ac7bab568d26dc._comment b/doc/forum/git-annex_teams___47___groups/comment_1_0450673ab74f184a47ac7bab568d26dc._comment
new file mode 100644
index 000000000..4b77da8f5
--- /dev/null
+++ b/doc/forum/git-annex_teams___47___groups/comment_1_0450673ab74f184a47ac7bab568d26dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T17:10:17Z"
+ content="""
+Anyone with access to a git repository can access all the files stored in it. git-annex does not try to change this, so you need to find a way to have one repository for each group.
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_4_3cbd06de53b6a13e2741124a8e7b5b5b._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_4_3cbd06de53b6a13e2741124a8e7b5b5b._comment
new file mode 100644
index 000000000..1868e9736
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_4_3cbd06de53b6a13e2741124a8e7b5b5b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 4"
+ date="2013-06-25T17:22:53Z"
+ content="""
+spwhitton, your analysis is correct -- except this problem was finessed in git-annex version 4.20130621. Now, when using direct mode, it knows that `old/song.mp3` is also `music/song.mp3`, and so it only drops it if the preferred content expression allows dropping both files.
+
+Still doesn't work in indirect mode, and I think not likely to in the forseeable future. See [[bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time]]
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_5_963558ab261d8a6315402d371e8348f9._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_5_963558ab261d8a6315402d371e8348f9._comment
new file mode 100644
index 000000000..f7ae3216a
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_5_963558ab261d8a6315402d371e8348f9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="82.36.235.9"
+ subject="comment 5"
+ date="2013-06-25T19:47:19Z"
+ content="""
+I assume you mean that if I use direct mode locally, it will get things right.  I didn't think a special remote could ever be in direct mode.
+
+Thank you for the info.  I don't want to lose the safeguards of indirect mode just for this, so I'll stick with my inelegant manual preferred content strings for now.
+"""]]
diff --git a/doc/install/Android/comment_2_74cccae04ea23a8600069c7e658143aa._comment b/doc/install/Android/comment_2_74cccae04ea23a8600069c7e658143aa._comment
new file mode 100644
index 000000000..bf5978674
--- /dev/null
+++ b/doc/install/Android/comment_2_74cccae04ea23a8600069c7e658143aa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 2"
+ date="2013-06-25T17:58:57Z"
+ content="""
+I have not heard of anyone using older than 4.x with success. In particular, several people reported 2.3 doesn't work.
+"""]]
diff --git a/doc/install/cabal/comment_8_738c108f131e3aab0d720bc4fd6a81fd._comment b/doc/install/cabal/comment_8_738c108f131e3aab0d720bc4fd6a81fd._comment
new file mode 100644
index 000000000..536f30da0
--- /dev/null
+++ b/doc/install/cabal/comment_8_738c108f131e3aab0d720bc4fd6a81fd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 8"
+ date="2013-06-25T17:16:46Z"
+ content="""
+git-annex 4.20130621 once again builds with the current version of yesod.
+"""]]
diff --git a/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_1_019a2457e07377510feaa089a93bd76c._comment b/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_1_019a2457e07377510feaa089a93bd76c._comment
new file mode 100644
index 000000000..4a59f37f1
--- /dev/null
+++ b/doc/todo/wishlist:_Have_a_preview_of_download_or_upload_size/comment_1_019a2457e07377510feaa089a93bd76c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T17:26:25Z"
+ content="""
+git-annex is designed to work with really large trees of files, and so it processes files one at a time in a stream. To get an overall estimate of the size, it would need to traverse the whole directory to get the total, and then traverse it again to perform the transfer. This would make no-op transfers take twice as long, which is why I'm unlikely to implement it.
+"""]]