# Is Git more useful for versioning binary files compared to versioning text files? [closed]

I am currently studying some basics on git Version Control System on tortoiseGit for my project management so far i know that Git keeps track of the history of changes, and allows you to easily go back to an earlier version if necessary.

However when it comes to binary vs text files I am unsure which files are more useful when it comes to Git versioning.

I have noticed that text files mentioned below can track changes from previous files but not consecutive lines as there will be a commit errors.

Binary files includes (.ppt, .jpg, .vpp, .pptx, .xlsx, .doc, .class)
text files includes (.java, .jsp, .txt, .html, .css)

Do you agree/disagree with the title statement? And why?

## closed as unclear what you're asking by gnat, Andres F., Doc Brown, David Arno, Greg BurghardtNov 19 '16 at 22:51

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• What exactly is "text files mentioned below can track changes from previous files but not consecutive lines as there will be a commit errors." supposed to mean? Git handles changes across consecutive lines just fine. You should only be encountering issues with non-trivial merges, such as different people modifying the same sets of lines and then combining their changes (and even then there are usually good ways of combining the two, assuming they haven't grown too different). – JAB Nov 18 '16 at 4:06
• No, not even close. – whatsisname Nov 18 '16 at 4:09
• @JAB yes i agree with you but say tim and james commit the same apple.txt file 1) tim changing line 13 and commit and push 2) james adding line 14-16 and commit and push. james would have fail because he fail to pull before he commit and push. – nathaniel Nov 18 '16 at 4:51
• @whatsisname can you explain why? – nathaniel Nov 18 '16 at 4:54
• "james would have fail because he fail to pull before he commit and push". Where James added the lines is irrelevant here: he should always commit, then pull (and then resolve merge conflicts if there are any, which there won't be in this case) and then finally push. – David Arno Nov 18 '16 at 9:39

Git doesn't care about the contents of files. At all. It stores a directory tree*. That's it.

It stores the names of directories and files, and their contents but without ever looking at the content. It simply stores it and retrieves it, it doesn't know anything about it.

There are higher-level tools that allow you to show the differences between different versions of a file, or merge diverging changes between different branches; these higher-level tools obviously do need to know about the contents of files. Git itself ships with some tools that can effectively and efficiently do that with semi-structured text files, but it is trivial to configure Git to launch other tools for other kinds of files, e.g. MS Word for diffing and merging Office OpenXML Text Documents, launching an XML merge program for XML files, launching an image diff program for images, etc.

* Actually, not even that is true, Git is even more abstract and general than that: Git stores trees of blobs, these blobs don't actually need to correspond to files and trees to directories or folders at all.

• I like the answer, but I think that the footnote confuses matters. Git stores objects of varying types. While you could use Git to store blobs without interpreting them as files, I don't think there's any way to interpret a tree or commit object other than the way they are used in Git. – kdgregory Nov 18 '16 at 15:25
• There are Git-based Wikis and issue trackers where e.g. blobs correspond to pages and trees to document hierarchies, not directories and files. Let's not forget that the Git commandline client is not the only client out there! Libgit, JGit and others allow you to programmatically interact with a Git repository on more of a database level than a filesystem level. At its core, Git is a versioned content-addressable tree database for unstructured bytestreams. Filesystems are also tree databases for unstructured bytestreams, and that is of course not a coincidence, but they are not the same. – Jörg W Mittag Nov 18 '16 at 15:39
• Linus originally called it a content-addressable filesystem, and IIRC the current tagline is "the stupid content tracker", where "stupid" is a feature, not a bug. – Jörg W Mittag Nov 18 '16 at 15:40

git is primarily a source control system. It's niche is that it's really, really great at keeping track of changes to text files and being able to re-incorporate those changes logically when branches are merged together. It can't do that with binary files.

Therefore, given the choice, use git for versioning text files over binary files. Sometimes you won't have a choice, but git's power lies in its ability to reconcile text changes across dramatically divergent branches.

• As written, this is incorrect. Git does not, in fact, "[keep] track of changes to text files". In reality, it maintains snapshots of entire directory trees, and relies on a diff utility to compare the contents of those trees. See Pro Git for an explanation of the object model, and my recent blog post for a demonstration of the changes to the object tree over a series of commits. – kdgregory Nov 18 '16 at 15:21
• I wasn't trying to explain how git works, only what its strengths and weaknesses are. – Stephen Nov 20 '16 at 22:25

You sometimes hear of cars getting stuck while driving off-road. You never hear of houses getting stuck like that. Does that mean houses have better mobility than cars? Of course not! You can't get your house stuck in an off-road drive because you can't drive your house at all.

You sometimes get line conflicts in text files when merging Git branches, but that's because Git actually attempt to do line merges for text files. You never get these conflicts with binary files because Git never tries to merge them in the first place.

Try it:

• Add a line to a JPG image in one branch
• And add another line to a totally different area of the same image in another branch.
• Merge them

Was Git able to produce a JPG with both new lines? No - it simply tells you there is a conflict and expects you to do things manually. If you tried the same thing with text files, Git would have tried to merge them automatically. It can could have failed - but only because it tried.

As Jörg W Mittag mentioned in his answer, you can configure Git to use diff tools for specific file types. If you set your Git to use an image diff tool for JPG files, it may be able to produce a JPG with both new lines - but in some cases it may also fail and require manual conflict resolution, just like with text files. Does this mean that by installing that tool you made Git less useful for JPGs?

BTW: this question is not that meaningful. You don't usually say "I have a Git repository, now I need to find files to version". It's usually the other way around - you have files you need to version, and you need to choose which source control is best for them. So the question is not how Git's handling of binary files compares to it's handling of text files - the question is how Git's handling of binary files compares to the binary files handling of other version control systems.

Version controlling binary files in version control systems such as GIT not the best use of the software. Even seemingly minor changes can result major changes in the binary file. This significantly increases the difference between the old and new files, which is what is tracked by the software.

GIT, SVN, CVS etc. are best used as source control systems. These handle source files which usually have minor changes. These can be stored in relatively small change set. Things like reformatting a source tree can be extremely disruptive as the different size can increase dramatically, and it becomes difficult to find semantic changes between versions.

GIT is far more capable of handling binary data. However, it will not be able to extract semantic difference from these files. It makes little sense to version control generated artifacts like .class files.

For documentation files, it may make more sense to use a text file in a common markup language. These can be easily managed with a source control system. It also minimizes issues with version mismatches between the document and the software that reads it.