diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2015-09-21 13:29:59 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2015-09-21 13:29:59 -0400 |
| commit | 3265c9d4a6e887bbaa22602438680cce876932b2 (patch) | |
| tree | 3ffe23fb848cbe7ee83a3f3086d1033a19fe3acb /doc/bugs | |
| parent | 7ea332f43e0f3e5f565714ef250ae8413a3ddbb9 (diff) | |
forwarded bug
Diffstat (limited to 'doc/bugs')
2 files changed, 22 insertions, 0 deletions
diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn index 35e5111b6..332748123 100644 --- a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn +++ b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn @@ -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]] diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment new file mode 100644 index 000000000..597c017de --- /dev/null +++ b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment @@ -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.. +"""]] |