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

forwarded bug

Browse source
This commit is contained in:
Joey Hess 2015-09-21 13:29:59 -04:00
parent 3058e11520
commit 5170e6ac1a
2 changed files with 22 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn
View file

@ -41,3 +41,5 @@ My diagnosis is that when running `git annex sync testremote --content` when the
(non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
failed
> fowarded, so [[closing|done]] --[[Joey]]

20
doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2015-09-21T17:09:16Z"
content="""
Analysis seems to make sense. Note that this happens only when gcrypt is
doing a push, not a pull, so there needs to be a local change made for the
sync to try to push out for the bug to occur. Reproduced by adding a file
and then syncing.
It seems that gcrypt recovers fairly well; after setting the local
remote.foo.gcrypt-id to a new value, when the network comes back, it
re-sets it back to the real value next time a pull is made. Does this
bug result in any problem other than noise in the log?
Anyway, it's certianly a gcrypt bug, and I don't see what git-annex can do
about it. Opened a bug there: <https://github.com/bluss/git-remote-gcrypt/issues/20>
Doesn't seem that this would be too hard to fix in gcrypt..
"""]]