mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2014-02-06 18:30:29 -04:00
commit e7ae56114b
7 changed files with 77 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
doc/bugs/Building_on_OpenBSD/comment_5_8aba96ef58eb6954f1d15029e0dda9ed._comment Normal file
View file

@ -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.
"""]]

9
doc/bugs/GPG_issues_with_pubkey___40__Again__63____41__/comment_3_980c149d7f9040f5e71e662d95a5fbf1._comment Normal file
View file

@ -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.
"""]]

8
doc/bugs/GPG_issues_with_pubkey___40__Again__63____41__/comment_3_c279f5cc3f96910287e72bf59120d02b._comment Normal file
View file

@ -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.
"""]]

14
doc/bugs/Incorrect_symlink_path_in_simple_submodule_use_case/comment_1_73b4dc5f90c8ba5634caee35cd31af1a._comment Normal file
View file

@ -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.)
"""]]

16
doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_3_fd39e6ceffd9bf0709658c34945d8699._comment Normal file
View file

@ -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.
"""]]

8
doc/not/comment_13_c5c20576388f18daba3af913b44fb001._comment Normal file
View file

@ -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.
"""]]

12
doc/todo/openwrt_package/comment_1_100d76109e04bc43979775d71b4152ac._comment Normal file
View file

@ -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.
"""]]