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

7 files changed, 77 insertions, 0 deletions

diff --git a/doc/bugs/Building_on_OpenBSD/comment_5_8aba96ef58eb6954f1d15029e0dda9ed._comment b/doc/bugs/Building_on_OpenBSD/comment_5_8aba96ef58eb6954f1d15029e0dda9ed._comment
new file mode 100644
index 000000000..89bd81b60
--- /dev/null
+++ b/doc/bugs/Building_on_OpenBSD/comment_5_8aba96ef58eb6954f1d15029e0dda9ed._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 5"
+ date="2014-02-06T17:10:59Z"
+ content="""
+Ok, I missed that uuid needs network-info. Actually, git-annex does not use that part of uuid (it does not put IP info in its uuids). There is a past version of uuid that did not depend on network-info. Perhaps you should first install it: `cabal install uuid-1.2.14`
+
+As far as it not finding or liking the sha* commands, it may be that it is not able to parse the OpenBSD output, or doesn't see the output it expects when testing them. These commands are only used as a minor optimisation, if not available it will fall back to using a haskell implementation which is a few percent slower (or faster) than the linux coreutils version of sha*. I don't know how the speeds compare on OpenBSD, but it's probably not worth worrying about.
+"""]]
diff --git a/doc/bugs/GPG_issues_with_pubkey___40__Again__63____41__/comment_3_980c149d7f9040f5e71e662d95a5fbf1._comment b/doc/bugs/GPG_issues_with_pubkey___40__Again__63____41__/comment_3_980c149d7f9040f5e71e662d95a5fbf1._comment
new file mode 100644
index 000000000..2c5bdc120
--- /dev/null
+++ b/doc/bugs/GPG_issues_with_pubkey___40__Again__63____41__/comment_3_980c149d7f9040f5e71e662d95a5fbf1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 3"
+ date="2014-02-06T21:53:23Z"
+ content="""
+I can reproduce this, but only when using the hook special remote, so it's some problem with it.
+directory special remote works ok.
+"""]]
diff --git a/doc/bugs/GPG_issues_with_pubkey___40__Again__63____41__/comment_3_c279f5cc3f96910287e72bf59120d02b._comment b/doc/bugs/GPG_issues_with_pubkey___40__Again__63____41__/comment_3_c279f5cc3f96910287e72bf59120d02b._comment
new file mode 100644
index 000000000..b5e9c3c21
--- /dev/null
+++ b/doc/bugs/GPG_issues_with_pubkey___40__Again__63____41__/comment_3_c279f5cc3f96910287e72bf59120d02b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 3"
+ date="2014-02-06T22:07:55Z"
+ content="""
+Actually, it seems to affect also S3 and other remotes that call setCreds.
+"""]]
diff --git a/doc/bugs/Incorrect_symlink_path_in_simple_submodule_use_case/comment_1_73b4dc5f90c8ba5634caee35cd31af1a._comment b/doc/bugs/Incorrect_symlink_path_in_simple_submodule_use_case/comment_1_73b4dc5f90c8ba5634caee35cd31af1a._comment
new file mode 100644
index 000000000..d8539041d
--- /dev/null
+++ b/doc/bugs/Incorrect_symlink_path_in_simple_submodule_use_case/comment_1_73b4dc5f90c8ba5634caee35cd31af1a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 1"
+ date="2014-02-06T16:58:54Z"
+ content="""
+Since the symlinks are committed to git, they can only point at one location, which is whereever the .git/annex directory was in the repository where they were created in the first place. You can run `git annex fix` in the submodule and it should correct the links. But then they'll point to the wrong location in the non-submodule clone of the repository.
+
+So, it seems you need to pick whether a given repository will be a submodule or not (and where it will be mounted in the parent repository if so), and stick with that choice. You can't have it both ways. 
+
+I cannot imagine any change to git-annex that could change this limitation. Except perhaps using direct mode everywhere, in which case where the symlinks point internally doesn't really matter..
+
+(<http://myrepos.branchable.com> might be a usable alternative to submodules for you, that does not have this problem.)
+"""]]
diff --git a/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_3_fd39e6ceffd9bf0709658c34945d8699._comment b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_3_fd39e6ceffd9bf0709658c34945d8699._comment
new file mode 100644
index 000000000..5b23df870
--- /dev/null
+++ b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_3_fd39e6ceffd9bf0709658c34945d8699._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 3"
+ date="2014-02-06T17:05:45Z"
+ content="""
+Recent versions of git-annex have tried to extend the --force option to be needed in any operation that can possibly cause data loss. This includes locking a file, since that throws away any changes.
+
+Note that `git annex lock` does not check if the file is unmodified. For a few reasons including 
+
+* some backends don't include a checksum
+* it would be expensive to check a checksum
+* the file could get modified after or during a checksum check, and those modifications would be missed
+
+If you are sure you want to throw away any changes, use --force as suggested. If not, use `git annex add $file`, and assuming you're using a checksumming backend, it will notice the file has not changed and do what you want `git annex lock $file` to have done in this case.
+"""]]
diff --git a/doc/not/comment_13_c5c20576388f18daba3af913b44fb001._comment b/doc/not/comment_13_c5c20576388f18daba3af913b44fb001._comment
new file mode 100644
index 000000000..38c96f707
--- /dev/null
+++ b/doc/not/comment_13_c5c20576388f18daba3af913b44fb001._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 13"
+ date="2014-02-06T17:00:59Z"
+ content="""
+Yes, git-annex ensures your configured [[numcopies|copies]] is met before dropping a file.
+"""]]
diff --git a/doc/todo/openwrt_package/comment_1_100d76109e04bc43979775d71b4152ac._comment b/doc/todo/openwrt_package/comment_1_100d76109e04bc43979775d71b4152ac._comment
new file mode 100644
index 000000000..78029694a
--- /dev/null
+++ b/doc/todo/openwrt_package/comment_1_100d76109e04bc43979775d71b4152ac._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 1"
+ date="2014-02-06T17:26:58Z"
+ content="""
+I would be quite happy if someone took care of adding git-annex to openwrt.
+
+I don't have time to personally handle packaging for different linux distributions myself. What I could do is add mips builds of git-annex to the existing standalone linux builds. These would need to be built the same way the arm builds are done, using a Debian chroot and qemu to run tools from it. This is rather a lot of work for me to set up, and I don't know if I'd have to do it for both little and big endian mips.
+
+Also, it seems that Debian does not currently have a working haskell toolchain for mips. Which may well mean that ghc is not in a working state on mips at all.
+"""]]