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-05-19 13:07:03 -04:00
commit ff6ac90138
14 changed files with 138 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/bugs/Auto_update_not_updating_to_newest_version/comment_6_8019fa061d74365ea72e32780d288eb4._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 6"
date="2014-05-19T17:06:30Z"
content="""
See [[git-annex_auto_upgrade_is_redundant]] for analysis of this problem.
"""]]

12
doc/bugs/git_annex_costs_not_working_as_expected_in_the_assistant/comment_3_17e9c2d29ddadcabc30ce884ffe0f853._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 3"
date="2014-05-19T16:44:19Z"
content="""
When the assistant wants to download a file, it queues a transfer from all remotes that are known to have the file, with the lowest cost remotes first. If it fails to get the file from the lowest cost remote, it automatically falls back to the next lowest cost, and so on.
If there's a bug here, I'd suspect strongly it's due to having 2 remotes with the same UUID.
Yes, I think I've found it. Assistant.TransferSlots.genTransfer calls performTransfer, which is passed only the Transfer, not the Remote. So it then looks up a remote with the UUID from the Transfer. To fix this, I will need to adjust the transferkeys command's protocol to include the name of the remote that should be used.
"""]]

10
doc/bugs/git_annex_list__47__whereis_and_uncommited_local_changes/comment_2_7c8d91d78608d717164cb3e825654654._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 2"
date="2014-05-19T17:04:16Z"
content="""
Direct mode and indirect mode behave the same here -- in indirect mode, if you unlock and modify a file, whereis will show the location of the annexed file, not the un-added version. In general all git-annex commands except of course `add` and `status` operate on the files that are staged in the index or committed, not un-staged files in the work tree. This is consistent with git's own behavior.
It is true that in direct mode, whereis will say that a file that has been modified is present locally, even though the modification has changed the only local copy of the file -- so it's not actually present locally. However, I don't think it makes sense to make whereis check if the file is actually still locally present before showing it is. whereis shows location tracking information, which can be out of date for many reasons.
"""]]

12
doc/bugs/remote_gcrypt_based_repos_and_conflicting_uuids/comment_4_7eb33c23223dfc634eb3c9c6621f7f3e._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 4"
date="2014-05-19T16:28:01Z"
content="""
I can reproduce this problem on OSX.
I've only gotten as far as seeing that the gcrypt repository never gets initialized as a git repository. It has a config file, but no objects are ever pushed to it. This is why gcrypt sees no repository there in subsequent runs.
This is a bug in gcrypt, so filed: <https://github.com/blake2-ppc/git-remote-gcrypt/issues/15>
"""]]