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

4 files changed, 52 insertions, 0 deletions

diff --git a/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment b/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment
new file mode 100644
index 000000000..de4be2556
--- /dev/null
+++ b/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 5"
+ date="2014-09-16T18:36:18Z"
+ content="""
+Note that --listen=address:port had to be removed.
+
+OTOH, the webapp can be run with a https certificate now, which makes remote access much more secure.
+
+The webapp will use HTTPS if it finds
+a .git/annex/privkey.pem and .git/annex/certificate.pem. Here's
+one way to generate those files, using a self-signed certificate:
+
+    openssl genrsa -out .git/annex/privkey.pem 4096
+    openssl req -new -x509 -key .git/annex/privkey.pem > .git/annex/certificate.pem
+
+"""]]
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment
new file mode 100644
index 000000000..90643ca9b
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:22:11Z"
+ content="""
+Why is this a problem? You can delete the branch at any time of course if it's in the way.
+
+It would be possible for `git-annex sync` to avoid creating the synced/master branch at all when syncing with a bare git repository, but this would actually make it less efficient and slower. Where currently it makes one push, updating the remote's master branch when possible, and forcing an update of its synced/master branch at the same time, it would instead need to first try to update remote's master, then check if that succeeded and if not force the update of synced/master. Also, it's not clear how to check if the push to master succeeded, since something else might update it further in a race.
+
+I suppose that `git annex sync/merge` could delete the local synced/* branches once it was done merging them. This wouldn't prevent `git pull` from pulling down those branches, though.
+"""]]
diff --git a/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment b/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment
new file mode 100644
index 000000000..a0c4e8222
--- /dev/null
+++ b/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:13:18Z"
+ content="""
+Only fscking can be scheduled. From the man page:
+
+       These  actions  are available: \"fsck self\", \"fsck UUID\" 
+
+It won't be expanded to allow arbitrary commands, because that would let anyone who you share an annex with schedule arbitrary commands to run on your computer..
+"""]]
diff --git a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment
new file mode 100644
index 000000000..1b5508f97
--- /dev/null
+++ b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:07:54Z"
+ content="""
+I started to make this change, and then I realized this problem: If a non-bare repository is made on an external drive, then to the user this is another place they can edit their files. Which means they will expect their changes made there to be committed. Which is highly problematic, because the assistant cannot be left running on an external drive or it won't be able to be unmounted. Or, a periodic `git annex add; git annex sync` could be run on the external drive, but that is a more expensive process (especially when run on a slow drive) and would not meet the expectations of users of the assistant that their changes will promptly propagate.
+
+So, I feel that leaving bare repositories is actually the best choice.
+"""]]