summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2013-07-31 12:19:55 -0400
committerGravatar Joey Hess <joey@kitenet.net>2013-07-31 12:19:55 -0400
commit880cd680914db27759fdfe60bfcd6d4cd47a3b23 (patch)
tree29e09bb4340734d91b45dd9e05be4f1ce63d997a
parent79e8517738aca8e841e7cc0977d32a64a538bf21 (diff)
parentf65ddaafe3f46dfe5ac8bd49e8429adc55958204 (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/backends/comment_3_fdcbf8727fdefb9942a54689234b9698._comment12
-rw-r--r--doc/bugs/Large_unannex_operations_result_in_stale_symlinks_and_data_loss/comment_8_5470e2f50e6506139ecb1b342371c509._comment10
-rw-r--r--doc/bugs/OS_X_10.8:_Can__39__t_reopen_webapp/comment_6_a4ad73530cd0f6621bcc6394d5f39af7._comment41
-rw-r--r--doc/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/comment_6_9881b0f2dfb0907a60c0da296bc3da3f._comment10
-rw-r--r--doc/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/comment_7_ca017b9d3bafea4cb31448c802f3834e._comment8
-rw-r--r--doc/forum/commit_current_workdir_state_in_direct_mode.mdwn5
-rw-r--r--doc/special_remotes/hook/comment_4_35d79b5ffa5a19056efcdc805070bc4b._comment18
-rw-r--r--doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes.mdwn2
-rw-r--r--doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_1_e7c5c46112a2406b873d08bbf53c40d8._comment8
-rw-r--r--doc/tips/downloading_podcasts/comment_5_79b3f8d678ac9f67df4c0cd649657283._comment8
-rw-r--r--doc/todo/windows_support/comment_9_259a0b1a6f4d8d1944173380adc5e7c8._comment8
-rw-r--r--doc/todo/wishlist:___39__whereis__39___support_in_the_webapp.mdwn4
12 files changed, 134 insertions, 0 deletions
diff --git a/doc/backends/comment_3_fdcbf8727fdefb9942a54689234b9698._comment b/doc/backends/comment_3_fdcbf8727fdefb9942a54689234b9698._comment
new file mode 100644
index 000000000..6f8b1ad7a
--- /dev/null
+++ b/doc/backends/comment_3_fdcbf8727fdefb9942a54689234b9698._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmicVKRM8vJX4wPuAwlLEoS2cjmFXQkjkE"
+ nickname="Thomas"
+ subject="Please be more specific about what information goes into the key"
+ date="2013-07-31T11:55:09Z"
+ content="""
+It's a bit confusing to read that SHA256 does not include the file extension from which I can deduct that SHA256E does include it. What else does it include? I used to \"seed\" my git-annex with localy available data by \"git-annex add\"-ing it in a temporary folder without doing a commit and than to initiate a copy from the slow remote annex repo. My theory was that remote copy sees the pre-seeded files and does not need to copy them again.
+
+But does this theory hold true for different file names, extensions, modification date, full path? Maybe you could also link to the code that implements the different backends so that curious readers can check for themselves.
+
+Thank you!
+"""]]
diff --git a/doc/bugs/Large_unannex_operations_result_in_stale_symlinks_and_data_loss/comment_8_5470e2f50e6506139ecb1b342371c509._comment b/doc/bugs/Large_unannex_operations_result_in_stale_symlinks_and_data_loss/comment_8_5470e2f50e6506139ecb1b342371c509._comment
new file mode 100644
index 000000000..7ac71b6b8
--- /dev/null
+++ b/doc/bugs/Large_unannex_operations_result_in_stale_symlinks_and_data_loss/comment_8_5470e2f50e6506139ecb1b342371c509._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRai_qFYPVvEgC6i1nlM1bh-C__jbhqS0"
+ nickname="Matthew"
+ subject="comment 8"
+ date="2013-07-31T14:17:19Z"
+ content="""
+Filenames are the index which users use to find their data.
+
+Leaving a broken symlink may not result in technical data loss, but can quite possibly result in the user being unable to find the data which was referenced by that filename (symlink), so in that case that data _is_ lost, in the true sense of the word (the user cannot find it). Telling the user their data exists _somewhere_ is not actually making the situation any better.
+"""]]
diff --git a/doc/bugs/OS_X_10.8:_Can__39__t_reopen_webapp/comment_6_a4ad73530cd0f6621bcc6394d5f39af7._comment b/doc/bugs/OS_X_10.8:_Can__39__t_reopen_webapp/comment_6_a4ad73530cd0f6621bcc6394d5f39af7._comment
new file mode 100644
index 000000000..a5f2d4fb1
--- /dev/null
+++ b/doc/bugs/OS_X_10.8:_Can__39__t_reopen_webapp/comment_6_a4ad73530cd0f6621bcc6394d5f39af7._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkfHTPsiAcHEEN7Xl7WxiZmYq-vX7azxFY"
+ nickname="Vincent"
+ subject="seems to work"
+ date="2013-07-31T09:37:36Z"
+ content="""
+I tried this as well.
+
+ % diff -u /Applications/git-annex.app/Contents/MacOS/git-annex-shell{.old,}
+ --- /Applications/git-annex.app/Contents/MacOS/git-annex-shell.old 2013-07-31 19:32:28.000000000 +1000
+ +++ /Applications/git-annex.app/Contents/MacOS/git-annex-shell 2013-07-23 14:12:36.000000000 +1000
+ @@ -22,4 +22,4 @@
+ export GIT_ANNEX_APP_BASE
+ fi
+
+ -\"$base/runshell\" git-annex-shell
+ +\"$base/runshell\" git-annex-shell \"$@\"
+
+ % ps ax|grep git|grep -v grep |wc
+ 0 0 0
+
+ <click the gui app icon>
+ <a new browser tab opens, running the assistant>
+ % ps ax|grep git |grep -v grep
+ 33124 ?? S 0:00.40 git-annex webapp -psn_0_31972988
+ 33133 ?? S 0:00.00 git --git-dir=/Users/me/annex/.git --work-tree=/Users/me/annex cat-file --batch
+ 33162 ?? S 0:00.00 git --git-dir=/Users/me/annex/.git --work-tree=/Users/me/annex cat-file --batch
+ 33174 ?? S 0:00.00 git --git-dir=/Users/me/annex/.git --work-tree=/Users/me/annex cat-file --batch
+ 33177 ?? S 0:00.00 git --git-dir=/Users/me/annex/.git --work-tree=/Users/me/annex check-attr -z --stdin annex.backend annex.numcopies --
+
+ <click the gui app icon again>
+ <a new browser tab opens, running the assistant. the original remains.>
+ % ps ax|grep git |grep -v grep
+ 33124 ?? S 0:00.46 git-annex webapp -psn_0_31972988
+ 33133 ?? S 0:00.00 git --git-dir=/Users/me/annex/.git --work-tree=/Users/me/annex cat-file --batch
+ 33162 ?? S 0:00.00 git --git-dir=/Users/me/annex/.git --work-tree=/Users/me/annex cat-file --batch
+ 33174 ?? S 0:00.00 git --git-dir=/Users/me/annex/.git --work-tree=/Users/me/annex cat-file --batch
+ 33177 ?? S 0:00.00 git --git-dir=/Users/me/annex/.git --work-tree=/Users/me/annex check-attr -z --stdin annex.backend annex.numcopies --
+
+HTH
+"""]]
diff --git a/doc/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/comment_6_9881b0f2dfb0907a60c0da296bc3da3f._comment b/doc/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/comment_6_9881b0f2dfb0907a60c0da296bc3da3f._comment
new file mode 100644
index 000000000..f1509b395
--- /dev/null
+++ b/doc/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/comment_6_9881b0f2dfb0907a60c0da296bc3da3f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawknruiCHUcOh2mmpkh7OFJ4iNfAOOamRVs"
+ nickname="Renaud"
+ subject="comment 6"
+ date="2013-07-31T05:34:33Z"
+ content="""
+Great, thank you very much!
+
+I successfully ran the test suite and it's now working fine.
+"""]]
diff --git a/doc/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/comment_7_ca017b9d3bafea4cb31448c802f3834e._comment b/doc/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/comment_7_ca017b9d3bafea4cb31448c802f3834e._comment
new file mode 100644
index 000000000..48173bff9
--- /dev/null
+++ b/doc/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/comment_7_ca017b9d3bafea4cb31448c802f3834e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Remy"
+ ip="82.94.186.146"
+ subject="comment 7"
+ date="2013-07-31T13:55:07Z"
+ content="""
+I got the same problem with the dummy symlinks while syncing to an annex on an EncFS mount on Ubuntu so I hope the fix doesn't just apply to Windows and Android.
+"""]]
diff --git a/doc/forum/commit_current_workdir_state_in_direct_mode.mdwn b/doc/forum/commit_current_workdir_state_in_direct_mode.mdwn
new file mode 100644
index 000000000..63945f790
--- /dev/null
+++ b/doc/forum/commit_current_workdir_state_in_direct_mode.mdwn
@@ -0,0 +1,5 @@
+I'd like to commit the current workdir state in direct mode in a script. This is what git annex watch does but I can not reliably start and stop git annex watch in a cron script.
+
+Is this already possible with the current api or could we have something like git annex watch --once?
+
+Thank you, Thomas Koch
diff --git a/doc/special_remotes/hook/comment_4_35d79b5ffa5a19056efcdc805070bc4b._comment b/doc/special_remotes/hook/comment_4_35d79b5ffa5a19056efcdc805070bc4b._comment
new file mode 100644
index 000000000..988d17def
--- /dev/null
+++ b/doc/special_remotes/hook/comment_4_35d79b5ffa5a19056efcdc805070bc4b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnWvnTWY6LrcPB4BzYEBn5mRTpNhg5EtEg"
+ nickname="Bence"
+ subject="checkpresent success and failure"
+ date="2013-07-31T13:06:21Z"
+ content="""
+What value should be returned in the \"checkpresent-hook\" to signal that the given file does not exist in the given backend?
+
+Should the called hook process return an exit code less or greater then zero? In this case the following is displayed:
+>(user error (sh [\"-c\",\"name_of_the_process\"] exited 1)) failed
+
+This tells that the process failed (no internet connection or something that prevents the process from doing its job) and not that result is false, which would mean the file/entry does not exist in the given backend.
+If the return code is zero the file is treated as existing file/entry (no matter what I write to stderr).
+
+Also I think, the \"checkpresent\" block misses the ending ;; in the example.
+
+Here is my work-in-progress hook: https://gist.github.com/parhuzamos/31bf4516eea434e0d248
+"""]]
diff --git a/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes.mdwn b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes.mdwn
new file mode 100644
index 000000000..0983c7d31
--- /dev/null
+++ b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes.mdwn
@@ -0,0 +1,2 @@
+When git annex does fsck on (for example) a GPG-encrypted special directory remote, it first transfers the whole file into .git/annex/tmp directory.
+If your annex is on an SSD, it's a good idea to make .git/annex/tmp a symlink to say /var/tmp so SSD isn't worn down. This actually may be a better default.
diff --git a/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_1_e7c5c46112a2406b873d08bbf53c40d8._comment b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_1_e7c5c46112a2406b873d08bbf53c40d8._comment
new file mode 100644
index 000000000..9c7bc2ed1
--- /dev/null
+++ b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_1_e7c5c46112a2406b873d08bbf53c40d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 1"
+ date="2013-07-31T15:15:41Z"
+ content="""
+Of course, this only works when /var/tmp isn't on SSD itself. Perhaps tmpfs (e.g. a /tmp on many distros) is good -- after checking that there's enough space to transfer a particular file.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_5_79b3f8d678ac9f67df4c0cd649657283._comment b/doc/tips/downloading_podcasts/comment_5_79b3f8d678ac9f67df4c0cd649657283._comment
new file mode 100644
index 000000000..f5df9910f
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_5_79b3f8d678ac9f67df4c0cd649657283._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ckeen"
+ ip="79.249.110.228"
+ subject="Force a reload of a feed?"
+ date="2013-07-31T10:35:50Z"
+ content="""
+Currently I have my podcasts imported with --fast. For some reason there are podcast episodes missing. This has been done propably during my period of toying with the feature. If I retry on a clean annex I see all episodes. My suspicion is that git-annex has been interrupted during downloading a feed but now somehow thinks it's already there. How can I debug this situation and/or force git annex to retry all the links in a feed?
+"""]]
diff --git a/doc/todo/windows_support/comment_9_259a0b1a6f4d8d1944173380adc5e7c8._comment b/doc/todo/windows_support/comment_9_259a0b1a6f4d8d1944173380adc5e7c8._comment
new file mode 100644
index 000000000..9ae337886
--- /dev/null
+++ b/doc/todo/windows_support/comment_9_259a0b1a6f4d8d1944173380adc5e7c8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlpSOjMH7Iaz56v6Pr9KCFSpbvMXvg-y9o"
+ nickname="Dominik"
+ subject="comment 9"
+ date="2013-07-31T10:29:51Z"
+ content="""
+The tradeoff for me is a \"local\" security hole (where I can secure my own laptop) vs. a remotely exploitable thing... If it needs to go through a file, so be it -- it would however be good if that file would be overwritten with garbage before being deleted :-)
+"""]]
diff --git a/doc/todo/wishlist:___39__whereis__39___support_in_the_webapp.mdwn b/doc/todo/wishlist:___39__whereis__39___support_in_the_webapp.mdwn
new file mode 100644
index 000000000..c074988b0
--- /dev/null
+++ b/doc/todo/wishlist:___39__whereis__39___support_in_the_webapp.mdwn
@@ -0,0 +1,4 @@
+I've looked for this feature in the webapp but can't find it...
+
+I mainly use the webapp and have been wondering 'how many copies of file X are there' and 'where are the copies of file Y'?
+This is available in the commandline interface but it would be nice to have this in the webapp too.