forwarded bug
This commit is contained in:
parent
3058e11520
commit
5170e6ac1a
2 changed files with 22 additions and 0 deletions
|
@ -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)
|
(non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
|
||||||
failed
|
failed
|
||||||
|
|
||||||
|
> fowarded, so [[closing|done]] --[[Joey]]
|
||||||
|
|
|
@ -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..
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue