In this article I focus only on limitations of Git compared to any other Revision Control System (RCS).
Git is a famous free open source RCS that uses a distributed model for repository and merge model for concurrency, released initially 10 years ago. It supports Windows, OS X, Linux and POSIX operating systems. It was written originally by the same author of the Linux Kernel – the famous 45-year old, holder of M.S. degree from University of Helsinki, the software engineer at the Linux Foundation – Linus Torvalds.
RCS’s in general are used to automate the storing, retrieval, logging, identification and merging of revisions. Simply, a RCS is useful for text that is revised frequently such as programs, documentation, procedural graphics, papers and form letters.
Regardless of its fame and all other features and commands, Git has limitations in the following areas:
File Renames (Partial)
File renames feature is to allow files to be renamed while retaining their version history.
Git does not explicitly track renames, because by design it does not track individual files. Renames and split of source files are detected after the fact, if the file content does not change dramatically.
International Support (Partial)
International support means supporting inter-operations under file systems using different character encoding.
Git itself is not internationalized, just git-gui and gitk, which are both shipped with git.
Large Repositories (Partial)
Large repository support feature means handling repositories of around a gigabyte or larger effectively.
Git has some issues with very large repositories. Large files are loaded into memory and they are converted into loose format. The binary files are loaded into memory entirely to determine whether they are binary or not. Many large files do not delta very well. Git copies and stores every object from a remote repository when cloning which consumes bandwidth and disk space for large files. Git is pretty slow when managing huge repositories in any given tree as it needs to rewrite the index in full for almost every operation. Cache-tree invalidation is a real problem for large files.
Keyword Expansion (Not supported)
Keyword expansion is an advanced feature that means supporting automatic expansion of keywords such as file revision number.
Keyword expansion is neither supported nor recommended by Git. The Git team justifies that this feature is the mother of all sorts of strange problems and isn't really useful anyway.
Permissions advanced feature means tracking files permission bits in the revision history.
Git supports only execution bit.
Time-stamp Preservation (Not supported)
Time-stamp preservation is an advanced feature that means overwriting the last modified file system attribute with the commit time upon checkout.
Git does not support time-stamp preservation and it does not recommend doing so in the future. It justifies that if other branch has older time-stamp than that of the derived file, the derived file will not be built even if it is different which leads to unhealthy and hard to resolve situation.
Shared build cache of derived objects (Not supported)
Shared build cache of derived objects is an advanced feature that means the ability to wink-in derived-objects that were built by other confederated clients that share exactly the same dependencies instead of rebuilding them locally. This feature is not supported in Git.
Lock/Unlock (Not supported)
Lock is a command that enables exclusively locking files in a repository from being changed by other users. Locking/unlocking is not supported in Git.
Copy is a command for marking specified files to be copied at next commit. In Git copies are detected after the fact, much like renames
Git has limitations in three basic features of a RCS that are: file renames, international support and big repositories. It also does not support some advanced features, such as keyword expansion, time-stamp preservation and shared build cache of derived objects. Git team also recommends avoiding keyword expansion and time-stamp preservation because the first is the mother of evil and it is not useful anyway and the second will probably cause unhealthy situations. Permission advanced feature supports only execution bit. For commands: lock/unlock command is not supported and copy suffers from the same condition as file renames; they are not detected until they are done.
Git is very powerful regardless of what was mentioned in this article, however, Git is not suitable in two situations, when the repository is very large and if you cannot live without the lock/unlock command. Finally, I wish that someday Git will overcome all the above limitations and become the most powerful fully-featured RCS worldwide.