Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2014-06-05 14:59:25 -04:00
commit cafe82b542
13 changed files with 149 additions and 0 deletions

View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 3"
date="2014-06-05T17:06:40Z"
content="""
> if we have an exact time difference of 1s (probably \"inode problem\") or 1h (\"utc problem\") we treat this file as likely unmodified and check this via the normal checksum algorithm.
That sort of makes sense, but when is git-annex supposed to do that?
If `git annex add`, it already checksums the file, and already stages no change if the file's checksum is the same. And if the user has told git-annex to add the file and it's changed, the presumption is they know it's changed and want to add the new version.
> To do an git annex sync or git annex add is in my opinion not a good option, because one could add so Bad file content by accident...
If not in add or sync, then when?
----
I am actually having a hard time coming up with a scenario where this problem results in any more than extra checksumming work by git-annex.
The only scenario I see is: The drive is unmounted, gets corrupted, is remounted, and this timestamp nonsense causes git-annex to think a file (that has already gotten corrupted) has in fact changed, so it commits the corrupted version.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://launchpad.net/~eliasson"
nickname="eliasson"
subject="comment 2"
date="2014-06-05T17:15:32Z"
content="""
Great. I will patiently await the next release.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 1"
date="2014-06-05T17:37:08Z"
content="""
I've reproduced this.
More simply: git annex move --to mybare and then git annex get will fail
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 2"
date="2014-06-05T18:29:15Z"
content="""
Appears to be a corrupt uuid log issue. At least, the bug I am seeing is. When retriving the uuid of the remote that has the key from the location log, it seems to get a uuid with one or more \r appended to it. Which smells of windows.
However, the bug I am seeing makes `git annex get` print out the uuids of the remotes without the description it normally shows (because these are not really the same uuids due to the \r). In the example above, this is not the case; the description is shown. I don't understand that.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 1"
date="2014-06-05T16:37:27Z"
content="""
I'm going to assume that the \"jessie/wheezy\" is a typo, since those are two completely different versions. It sounds to me like you were using the git-annex 3.x distributed with debian stable.
I cannot reproduce ssh port issues with the current release, and there have been ssh port fixes in the over 2 years since the version in Debian stable.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="jamieson"
ip="71.11.173.17"
subject="comment 2"
date="2014-06-05T16:50:20Z"
content="""
Jessie on one machine, Wheezy on the other; exactly, that is the version I was using. Git Annex is awesome. Thanks!!
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 3"
date="2014-06-05T16:50:30Z"
content="""
I did notice a problem where the same ssh config stanza was used if the webapp set up a repository on a host first using one port, and later using a different port. I've fixed that.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 4"
date="2014-06-05T16:51:42Z"
content="""
Did the failure occur on the machine running jessie, or on the machine running wheezy?
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="jamieson"
ip="71.11.173.17"
subject="comment 5"
date="2014-06-05T16:56:33Z"
content="""
I'm not sure. I'll do some more testing!
"""]]