File: comment_3_429ec656e0ac02f98843f8d7f3c02d6a._comment

package info (click to toggle)
git-annex 5.20141125%2Bdeb8u1
  • links: PTS
  • area: main
  • in suites: jessie
  • size: 37,832 kB
  • sloc: haskell: 42,603; sh: 1,080; ansic: 498; makefile: 316; perl: 125
file content (11 lines) | stat: -rw-r--r-- 868 bytes parent folder | download | duplicates (11)
1
2
3
4
5
6
7
8
9
10
11
[[!comment format=mdwn
 username="https://me.yahoo.com/a/IAg3idYGk.joxsJb2WCxl20gig.0.8hS#d5165"
 nickname="Kelly"
 subject="comment 2"
 date="2012-05-09T01:22:13Z"
 content="""
What were the ideas to avoid parameterisation? What were the problems of parameterisation, other than just the current hardcoded assumptions?

Speaking of hash insecurity, http://static.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/node8.html says compare-by-hash is a bad idea. As I understand, git doesn't have an option of verifying content matches when the hash matches when adding data to the object store (like zfs's \"dedup=verify\" option, which you can use even when using sha256), because the assumption is that the risk of collision (or at least just the risk of accidental collision) is negligible. Would it be worthwhile to add this option to git-annex?

"""]]