diff options
author | Joey Hess <joey@kitenet.net> | 2014-02-06 18:30:29 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2014-02-06 18:30:29 -0400 |
commit | 112f91ecaf898888c02561f37b3e91afc42d2bbe (patch) | |
tree | 12f643087dd948529801c52b6f95377124507659 | |
parent | 1f76551dce12e7209422ee65980315bb60eb771a (diff) | |
parent | 715d5933366f743b10ab71e64111e22575ff6deb (diff) |
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. +"""]] |