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

11 files changed, 128 insertions, 0 deletions

diff --git a/doc/bugs/Direct_mode_keeps_re-checksuming_duplicated_files/comment_3_6a6d22d218f036c9977072973ed99aa8._comment b/doc/bugs/Direct_mode_keeps_re-checksuming_duplicated_files/comment_3_6a6d22d218f036c9977072973ed99aa8._comment
new file mode 100644
index 000000000..8f4e9bc86
--- /dev/null
+++ b/doc/bugs/Direct_mode_keeps_re-checksuming_duplicated_files/comment_3_6a6d22d218f036c9977072973ed99aa8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="identical filename"
+ date="2013-04-06T09:09:17Z"
+ content="""
+Same happens, with identical filename+content just in a different subdirectory.
+
+    annex/a.txt
+    annex/back/a.txt
+"""]]
diff --git a/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work.mdwn b/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work.mdwn
new file mode 100644
index 000000000..0e950f360
--- /dev/null
+++ b/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work.mdwn
@@ -0,0 +1,14 @@
+What steps will reproduce the problem?
+1. Create a Repository
+2. Add a Remote Server
+
+What is the expected output? What do you see instead?
+The option "Use a git repository on the server" is marked as not available
+
+What version of git-annex are you using? On what operating system?
+Version: 4.20130405 but on Webapp ist shows: Version: 4.20130324
+Linux 64bit
+
+Please provide any additional information below.
+git and git-annex are available on the Remote Server
+
diff --git a/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work/comment_1_2143f0540fdcd7efeb25b5a3b54fe0fd._comment b/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work/comment_1_2143f0540fdcd7efeb25b5a3b54fe0fd._comment
new file mode 100644
index 000000000..aa8237c17
--- /dev/null
+++ b/doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work/comment_1_2143f0540fdcd7efeb25b5a3b54fe0fd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-06T16:38:46Z"
+ content="""
+Well, it works here. It checks that all of `git`, `rsync`, and `git-annex` are in the path on the remote server using `which`.
+
+I think the most likely reason would be if you've installed git-annex on the remote server but not in the PATH. If you're using the standalone tarball, for example, it's \"installed\", but it has no way to find it.
+
+Or, you could have installed from cabal, which puts it in ~/.cabal/bin or ~/bin or something like that, and perhaps you configured your shell to put that directory in the PATH, but you did it in a way that only works for login shells. If you set the PATH in `~/.bashrc`, for example, that would not work for a noninteractive shell.
+"""]]
diff --git a/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add.mdwn b/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add.mdwn
new file mode 100644
index 000000000..230841e9f
--- /dev/null
+++ b/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add.mdwn
@@ -0,0 +1,24 @@
+What steps will reproduce the problem?
+
+Unable to reproduce as it seems to happen randomly, to very few files (4/250).
+
+What is the expected output? What do you see instead?
+
+I expect to see the assistant warn if it attempts to add a file which fails to add to the annex.
+Instead, I see no output from the assistant, but lines like this in the log.
+
+daemon.log.2:add Indie Game Stand/Deadly 30/Deadly30_MAC.zip (checksum...) failed
+daemon.log.2:add Indie Game Stand/Wyv and Keep/xnafx40_redist.msi (checksum...) failed
+daemon.log.2:add Indie Game Stand/Blueberry Garden/Blueberry_Garden_1.1.zip (checksum...) failed
+daemon.log.2:add Indie Game Stand/Flatspace Bundle/fsmusicpack3setup.exe (checksum...) failed
+
+There is no reason given for the failure in the log file. The assistant also never tries to add them again in normal running (but did add them when it was started again after a reboot).
+
+What version of git-annex are you using? On what operating system?
+
+git-annex version: 4.20130314
+OS: Arch Linux
+
+Please provide any additional information below.
+
+The assistant in this case is being used as nothing more than a way for me to see which files have been added (--verbose, --foreground and --debug with 'watch' outputs nothing..). No remotes or anything like that.
diff --git a/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add/comment_1_13b2f93b7d09c8fd6c22829a0dc6428b._comment b/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add/comment_1_13b2f93b7d09c8fd6c22829a0dc6428b._comment
new file mode 100644
index 000000000..02db48da7
--- /dev/null
+++ b/doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add/comment_1_13b2f93b7d09c8fd6c22829a0dc6428b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-06T16:34:00Z"
+ content="""
+The assistant runs a daily sanity checker job which will clean up files like these. (`git annex watch` does not, however).
+
+I think the main reason add could fail is if a file gets modified while it's in the process of being added. It could retry right away, although it needs to do it in a way that does not loop if the file continually fails to be added.
+"""]]
diff --git a/doc/bugs/git-annex_add_should_repack_as_it_goes/comment_3_ff8b589fbcf25c98abd1c58830074650._comment b/doc/bugs/git-annex_add_should_repack_as_it_goes/comment_3_ff8b589fbcf25c98abd1c58830074650._comment
new file mode 100644
index 000000000..e60460443
--- /dev/null
+++ b/doc/bugs/git-annex_add_should_repack_as_it_goes/comment_3_ff8b589fbcf25c98abd1c58830074650._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-06T06:32:56Z"
+ content="""
+More testing shows that only the first git commit is slow. A second commit will be fast whether or not `git-repack` has been run in between.
+"""]]
diff --git a/doc/design/assistant/blog/day_230__Mom/comment_1_696bba2246c8a9e6ce4aed3071bcc96c._comment b/doc/design/assistant/blog/day_230__Mom/comment_1_696bba2246c8a9e6ce4aed3071bcc96c._comment
new file mode 100644
index 000000000..5b8b8187f
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom/comment_1_696bba2246c8a9e6ce4aed3071bcc96c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="68.35.120.66"
+ subject="comment 1"
+ date="2013-04-05T23:50:14Z"
+ content="""
+This is probably a Dumb Git Question, but is there a tag in the repo for the new release?  I go into my clone and type \"git tag\" and the latest one I see is 4.20130323.
+"""]]
diff --git a/doc/design/assistant/blog/day_230__Mom/comment_2_2fa295ab6db0828cb725cfcfb6777822._comment b/doc/design/assistant/blog/day_230__Mom/comment_2_2fa295ab6db0828cb725cfcfb6777822._comment
new file mode 100644
index 000000000..3f1666d89
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom/comment_2_2fa295ab6db0828cb725cfcfb6777822._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="deletions by mistake?"
+ date="2013-04-06T04:58:09Z"
+ content="""
+Let's say a family member deletes a file by mistake in a synced diretory?  Looks like this kind of error is easy to go unnoticed.  What would be a good way to handle this?
+"""]]
diff --git a/doc/design/assistant/blog/day_230__Mom/comment_3_fafd7abec629290418334ddb015bf62c._comment b/doc/design/assistant/blog/day_230__Mom/comment_3_fafd7abec629290418334ddb015bf62c._comment
new file mode 100644
index 000000000..9cfa45aca
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom/comment_3_fafd7abec629290418334ddb015bf62c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-06T16:26:57Z"
+ content="""
+Weird, I don't know where the tag went. I've pushed a new one.
+
+If a file is deleted, it's still there in git, and git-annex hangs onto its contents. You need a git history browser to get it back of course.
+"""]]
diff --git a/doc/design/assistant/blog/day_230__Mom/comment_4_450cac0f2e82c94fd34b527ae05ef1b8._comment b/doc/design/assistant/blog/day_230__Mom/comment_4_450cac0f2e82c94fd34b527ae05ef1b8._comment
new file mode 100644
index 000000000..56c8d3204
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom/comment_4_450cac0f2e82c94fd34b527ae05ef1b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlUbH3eytydcwlWqv8oauE2Jg4NwcV9uA0"
+ nickname="Anna"
+ subject="me!"
+ date="2013-04-06T18:22:30Z"
+ content="""
+I want in on the family repository! :-)
+"""]]
diff --git a/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_2_d67793f7c969f64943d1fd54a1208c2b._comment b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_2_d67793f7c969f64943d1fd54a1208c2b._comment
new file mode 100644
index 000000000..1dff89121
--- /dev/null
+++ b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_2_d67793f7c969f64943d1fd54a1208c2b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="163.1.166.255"
+ subject="comment 2"
+ date="2013-04-06T19:06:24Z"
+ content="""
+Thanks for taking the time to reply.
+
+1) The corruption spread between repositories so I resorted to restoring from a backup from some days ago, and then I restored newly added files by manually copying the symlinks from the old repo into the new one.  Of course I can't update the git-annex branch by hand.  I've run `git annex fsck`: does that re-create the location log information for the symlinks that I re-added, at least for the local repository even if it doesn't know about copies elsewhere?
+
+2) I initially tried to git clone from my restored backup, rather than just moving the restore into place.  But then while this clone showed no errors on a `git fsck --full`, any git-annex command, such as `init` (following [this](http://git-annex.branchable.com/tips/what_to_do_when_a_repository_is_corrupted/)), gives the following sort of error:
+
+    error: invalid object 100644 <long-SHA-string> for '<path to one of git annex's log files>'
+(unfortunately I lost my xterm so don't have one of my actual errors in full).  Can you think of any reason why doing a clone of the backup copy would cause this?  Instead I have just mv'd the backup copy into place and it works fine.
+"""]]