On 25/10/19 07:32PM, без имени wrote: > > Or were you thinking of some other meaning for "files stored in a single (current) state"? > > It means that new versions of files located in `.git / binary` will completely replace old versions in history, and therefore will be in a single (current) state in history. What used to be another version of this file should be ignored (very useful for PNG, JPEG, PDF). Something like this might have trouble working with checkouts of past commits, which is a major reason (at least for me) for using a version control system. Say you have two files marked as "binary" A.png and B.png at commit X. Some part of your code references those files. Now let's say you make a new commit Y where you remove A.png. You also remove all references to A.png in your code since you don't need it anymore. In your suggested system, we drop A.png. Now if you checkout the commit X, A.png does not exist. This means your code won't compile or work properly, defeating the purpose of version control. You can argue that "how about we keep deleted files in history, but for the files that are modified, we don't keep their history, just the latest version?". For that argument, consider the following: say you have a commit X which has A.png. A.png has the dimensions 200x200. You make a new commit Y where you make A.png larger, say 400x400. Now if you checkout X, A.png is still 400x400 since we didn't track its history. And so, the behaviour of your software at that point might also change, defeating the purpose of version control. So instead, I'd point you to git-lfs [0]. I haven't personally used the tool ever, but it _might_ help in your use case. [0] https://git-lfs.github.com/ -- Regards, Pratyush Yadav
