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

9 files changed, 159 insertions, 1 deletions

diff --git a/doc/bugs/fsck_giving_false_checking_information.mdwn b/doc/bugs/fsck_giving_false_checking_information.mdwn
new file mode 100644
index 000000000..225985c56
--- /dev/null
+++ b/doc/bugs/fsck_giving_false_checking_information.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+When a repository has no object of a given file and git annex fsck is run it still shows "fsck file ok", which is missleading in the sense, that it gives the impression that it checked the file is alright/checksummed.
+
+As a result of this it seems that incremental fscks are not incremental with non checkable objects. On each run (after the first one) with "git annex fsck --incremental --more --schedule-limit 1d" all files without objects are checked even so it should wait another day till it checks again.
+
+Probably best to say checksum couldn't be checked on x files (only give that as quiet output, not every check)
+
+Another thing, which came up as a problem was, that checksum fsck would not be wanted to run as often as numcopie checks.
+When the incremental fsck is used to check for bad files "git annex fsck --incremental --more --limit 1m" after a fast numcopies check "git annex fsck --incremental --more --limit 1m fast" it messes up the actual bad files check.
+As both are currently using the same incremental "lock"-file they are colliding.
+
+### What steps will reproduce the problem?
+-
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 5.20140210-gd99db49
+Linux (Ubuntu 13.10)
+
+### 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/bugs/fsck_giving_false_checking_information/comment_1_1000603ea6b8a19eb09e6754789ad528._comment b/doc/bugs/fsck_giving_false_checking_information/comment_1_1000603ea6b8a19eb09e6754789ad528._comment
new file mode 100644
index 000000000..af198c722
--- /dev/null
+++ b/doc/bugs/fsck_giving_false_checking_information/comment_1_1000603ea6b8a19eb09e6754789ad528._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="stp"
+ ip="188.193.207.34"
+ subject="Earlier version syntax was removed"
+ date="2014-02-17T16:05:34Z"
+ content="""
+In earlier versions I noticed that when checksumming it would give back \"fsck file (checksum...) ok\" instead of \"fsck file ok\", which is at least better than not differentiating. This should definitely be improved. Perhaps even clearer than the (checksum...) notice.
+
+But still the incremental run not being incremental and not taking into account the schedule-limit seems strange.
+"""]]
diff --git a/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn
new file mode 100644
index 000000000..a9426724c
--- /dev/null
+++ b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+When "git annex sync --content" is used only objects currently in the working tree are synced. It doesn't honor full archives, which should get all objects.
+So only objects similar to "git annex find --want-get" are synced and not every available object "git annex get --all"
+
+
+### What steps will reproduce the problem?
+# mein repo:
+git annex add file
+git annex sync
+git annex rm file
+git annex sync
+
+# other repo:
+git annex wanted here "not copies=backup:3"
+git annex find --want-get # will be empty
+git annex sync --content # nothing is synced even so all files should be backed up
+git annex get --all # will sync the object from file
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 5.20140210-gd99db49
+Linux (Ubuntu 13.10)
+
+### 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/bugs/numcopies_deprecated__44___but_still_in_walkthrough.mdwn b/doc/bugs/numcopies_deprecated__44___but_still_in_walkthrough.mdwn
new file mode 100644
index 000000000..7d4044baf
--- /dev/null
+++ b/doc/bugs/numcopies_deprecated__44___but_still_in_walkthrough.mdwn
@@ -0,0 +1,19 @@
+### Please describe the problem.
+Within the walkthrough the deprecated annex.numcopies are still used. At least it should be added that "git annex numcopies x" can be used to define it globally without the need for a .gitattribute file. And use .gitattribute only for per directory and fine grained control.
+http://git-annex.branchable.com/walkthrough/backups/
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+### 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/forum/new_linux_arm_tarball_build/comment_8_6db99d998ca990494c8f2826ff1ca273._comment b/doc/forum/new_linux_arm_tarball_build/comment_8_6db99d998ca990494c8f2826ff1ca273._comment
new file mode 100644
index 000000000..9d58cb11c
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_8_6db99d998ca990494c8f2826ff1ca273._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://renaud.casenave.fr/"
+ ip="126.10.66.235"
+ subject="comment 8"
+ date="2014-02-17T13:15:24Z"
+ content="""
+Hi,
+
+You might be happy to know git-annex works well on sailfishOS, even the webapp.
+It does segfault when trying to setup a xmpp account, though.
+"""]]
diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_2_f32412f8d3b84cd5cb3c4d5d6bb60f32._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_2_f32412f8d3b84cd5cb3c4d5d6bb60f32._comment
new file mode 100644
index 000000000..7acee2035
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_2_f32412f8d3b84cd5cb3c4d5d6bb60f32._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3rK4VDzxyhmrIc18z7F5OuXvEbUsgUac"
+ nickname="Srinath"
+ subject="Progress, but still issues"
+ date="2014-02-17T04:09:23Z"
+ content="""
+\"I now realize that the git annex system still requires the standard \"add\" and \"commit\" process. But I'm still getting:
+
+$git annex sync
+commit  ok
+pull origin 
+remote: Counting objects: 37, done.
+remote: Compressing objects: 100% (35/35), done.
+remote: Total 36 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (36/36), done.
+From ssh://stampede.tacc.utexas.edu/work/02463/srinathv/cesm1_3_beta07/scripts
+ * [new branch]      master     -> origin/master
+
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+push origin 
+Counting objects: 11, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (8/8), 736 bytes | 0 bytes/s, done.
+Total 8 (delta 3), reused 1 (delta 0)
+To ssh://srinathv@stampede.tacc.utexas.edu/work/02463/srinathv/cesm1_3_beta07/scripts
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+ok
+git-annex: sync: 1 failed
+
+
+So the fails appear, and the suggestion of \"export PATH\" placement did not help, though appreciated.
+"""]]
diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_3_dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_3_dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment
new file mode 100644
index 000000000..53419452c
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_3_dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3rK4VDzxyhmrIc18z7F5OuXvEbUsgUac"
+ nickname="Srinath"
+ subject="no more issue"
+ date="2014-02-17T04:25:31Z"
+ content="""
+After doing 1 more sync, the error messages are now gone.  I wonder if the refs directory needed to be synched correctly.
+"""]]
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 39577190f..1b7271092 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -517,7 +517,7 @@ subdirectories).
   have been fscked. And once it's done, you'd like a new fsck pass to start,
   but no more often than once a month. Then put this in a nightly cron job:
 
-        	git annex fsck --incremental-schedule 30d --time-limit 5h
+        	git annex fsck --incremental --more --incremental-schedule 30d --time-limit 5h
 
   To verify data integrity only while disregarding required number of copies,
   use `--numcopies=1`.
diff --git a/doc/todo/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn b/doc/todo/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn
index 3a891fc9b..8b6350a55 100644
--- a/doc/todo/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn
+++ b/doc/todo/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn
@@ -37,3 +37,19 @@ in my opinion, the messages should at least contain
 
 >> Closing as this is literally impossible to do without making
 >> git-annex worse. [[done]] --[[Joey]] 
+
+> I'm not sure that the requested feature is that far off. There are two
+> aspects, that can be solved relatively easy:
+>
+>  * Recording the name of the remote the commit was issued on. This
+>    information is simply constant per remote.
+>
+>  * While it is true that there is no 1 on 1 correspondence between commands
+>    and git-annex commits, it would be entirely possible to add a "message
+>    journal". Every command issued would start out with writing its
+>    invocation to the message journal. At the time the journal ends up being
+>    committed to the git-annex branch, the message journal is used as the
+>    body of the commit message and truncated.
+>
+> It is true that these suggestions do not address every aspect of the
+> original report, but they would solve about 90%. --[[HelmutGrohne]]