On Mon, Apr 24, 2017 at 4:47 PM, Rm Beer <rmbeer2@xxxxxxxxx> wrote: > 2017-04-24 3:13 GMT-03:00 Jacob Keller <jacob.keller@xxxxxxxxx>: >> So, clearly you haven't defined the request very well. It *sounds* >> like what you want is the ability to say "git please store and >> copy/send this file to other people, but only store it once, and don't >> allow storing history of it". This pretty much defeats the entire >> point of revision control and doesn't make sense to me as part of a >> revision control system. > > Not have sense the save history of revision control system for any > binary files datas, who need save a multiple files by change any bytes > from a files? Where i change any pixel of image, a word of odt/doc, or > sound, music, driver, etc. In this case you only need 1 copy in the > repository of .git , you not need a 100 copys in the .git, one by each > day of change. You need a old image with a wrong pixel? not have > sense... > Please don't drop the list :) If you're not interested in tracking the revision history of a file, it doesn't need to be stored inside a revision control system. Instead, you probably want an alternative method for sharing such a file. Git is primarily about tracking changes over time to a collection of files in a project. It's also somewhat about sharing this history to other people, but I wouldn't say that is its primary goal. In either case, you could instead use an alternative mechanism for sharing the large binary file and have people grab the file this way. However, it is incredibly valuable to share the history of a file so that the other users can see what changed or make sure that the version they are using works with the version of the other sources they have. In the case of binary files, you might want to use alternative diff drivers to compare changes more easily, or instead provide some non-binary data that is used to generate the binary files (such as source code). The whole point of revision history is to show that "hey this used to have a wrong pixel, and now we fixed it, and here's how we did it". Maybe the "wrong" pixel was actually correct and you find out later that you need to revert this change. But the "later" is many months and you no longer have the exact change so you're using memory or external data to determine what to change again instead of the actual history of a file. Thanks, Jake