Thanks for reply. I know it is not a common scenario in real world, but when we put our valued code and docs in git, we hope git will be robust enough to take good care of our docs, and wont fall because of some unconscious behavior.
在 2018年6月27日星期三 UTC+8下午4:00:21，Konstantin Khomoutov写道： > > On Wed, Jun 27, 2018 at 12:29:25AM -0700, 11411...@qq.com <javascript:> > wrote: > > > I have done a test in version 2.18 to test how git handle hash > collision: > > 1、I commit pdf file 'shattered-1.pdf' into my local repo. the > generated > > hash for the file is '9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0' in dir > 'ba' > > 2、I change the content of '9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0' to > > store some other content > > 3、then i commit another file named 'shattered-3.pdf' which is exactly > the > > same as original 'shattered-1.pdf' to my local repo. > > > > I expect git to reject my commit because the newly generated object have > an > > duplicate hash with and old object but the content is different. But git > > accept my commit supprisingly.I checkout 'shattered-3.pdf' in another > > computer and the content is completely different with the one i > > meant to commit. > > > > Git should reject my commit to avoid such strange behaviour. When we > create > > a new object and the hash collides with an old object in our repo, we > can > > compare the object content byte by byte, if they are exactly the same, > we > > can use that old object directly, else we just stop creating the object > > with an error. Out repo will not be corrupted !! > > Hi! > > This horse has been beaten to death already. > > Please start with [1] then consider [2] and if that will be not enough, > consider researching the results of [3] and similar queries (search for > "collisions", "preimage", "stuffing", "attack" and the other usual > suspects). > > An executive summary is: > > - The devs are well aware of this problem. > > - They are trying to do something about this. > > - Doing this is not an easy task for a number of reasons. > But still they're on it. > > - They think that in most real-world scenarios the problem you have > presented is unlikely to happen. > Still, they intend to solve it anyway. > > All-in-all, this particular list is for helping newbie users solving > their problems they have when _using_ Git; the question of its > development are discussed on another — main — Git list which is [4]. > > 1. > https://public-inbox.org/git/20170304011251.ga26...@aiede.mtv.corp.google.com/ > > 2. > https://public-inbox.org/git/20180609205628.gb38...@genre.crustytoothpaste.net/ > > 3. https://public-inbox.org/git/?q=shattered > 4. http://vger.kernel.org/vger-lists.html#git > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
