Why not just fork git and make it better at binary files?

eru an hour ago | parent | next [-]

You don't even need to fork it: git has something like a plugin system for exactly this use-cases. (I'm not exactly sure what their terminology is. But they thought about this use-case before.)

▲

DanielHB 2 hours ago | parent | prev [-]

Problem with dealing with binary files with git (or source control in general) is that you want to be able to see diffs, which is very dependent on the type of binary file you have.

I think you can create git plugins to show diffs in different formats for certain file-types (or even open a 3rd party tool to let you visualize it), but it is a lot of work. Most productivity tools don't have anything of the sort.

If you just care about storing the file git LFS + manual text-changelog per binary file works well, but it is annoying to get everyone on your team to work in this workflow (heck, getting everyone and all automation scripts to install LFS is already a pain).

▲

gmueckl an hour ago | parent [-]

The problem is really starting g with a coders mindset that reducing a change to an explicit visual representation of a minimal delta is such a useful thing for everybody. It isn't. For example, for images, an A/B comparison is enough in a lot of cases. There are also no meaningful ways to "merge" changes for a lot of data outside source code, so the insistence that version control can't exist without merging is shortsighted.

Meaningful deltas and meaningful merges are actually a problem set that is totally and utterly disjointed from keeping the underlying change history. Deltas and merges can always be computed independently of the underlying storage format for versioned data. Git could have indicriminately used binary deltas for file storage and would still work the same on every higher layer.

	▲	eru an hour ago \| parent [-]
		In Git the deltas (or diffs) are derived data. They aren't central to what Git is. Natively and conceptually, Git works with repository snapshots.