mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 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
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.)
"""]]