9 ms·

Git is overrated. Other problems include: o Complex, confusing terminology including multiple non-obvious names for various components. o Huge number, about

Git is overrated. Other problems include: o Complex, confusing terminology including multiple non-obvious names for various components. o Huge number, about 148, of commands with many sub-commands that often do non-obvious, even unrelated things. o git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system. o Git has been bundled with code review systems like Gerrit which encourages developers to rebase heavily to create a false history presenting themselves as fantasy 10X programmers who don't make mistakes, debug, engage in trial and error, or all the other things developers actually do. When a bug does slip through as if often does despite the supposed quality-control benefits of code review, then reconstructing what happened from the rebased "history" can be a nightmare. o There are numerous commands to do similar, overlapping but nonetheless different tasks. If for example you want to back up to earlier versions of code you can do git revert, git reset --hard, git reset --soft, git checkout -- <SHA>, git checkout <SHA> -- all of which do different but overlapping things. o A supposed virtue of git is that it makes it extremely easy to create "branches." This often leads to a proliferation of branches, making locating changes and reconstructing the history of changes extremely difficult. A change can occur on a local branch on one developer's computer, be rebased into another local branch and then finally rebased or merged into the shared "master" branch. o Cryptic hexadecimal SHA for identifying commits instead of sequential numbers for individual files as well as snapshots of the entire project. Even if you track down the tricks to compile the SHA into a program or file name, the SHA is not sequential making it difficult to know which version of a file or group of files is in a program. o These many flaws in git and its command line interface have resulted in a proliferation of third-party add-on tools like the Android project's repo utility, gitk, magit in Emacs, sourcetree, many of which fail to fully wrap the complexity of Git forcing users to both master the wrapper tool and the Git command line especially on more complex projects. Some of these GUI/wrapper tools like Android repo seem to have serious bugs as well. o Lack of backward compatibility with RCS-style version control systems like Subversion. Instead of building on 30+ years of success and experience with RCS-style version control systems, but extending them sensibly for distributed projects, Git took a "reinvent the wheel badly" approach. o A fanatical, cult-like following apparently mesmerized by Linus Torvalds that is unable to recognize or acknowledge the many obvious problems with Git. Yours truly, Bit by Git

SeoxyS 12y ago
Sounds like you were bit by rebasing, rather than by git itself. Yes, the API is large and complex. But git itself is easy to learn, and extremely powerful. Whatever situation you might have gotten yourself into, git probably has a good way to handle it. There's one rule I abide by, which makes my git usage sane: no rebasing. Everything stays in the history, and there's no reason to squash commits into one giant context-less commit. The only common case in which rebasing is valuable is in getting rid of meaningless commits constantly merging the latest master into a feature branch.
- cozuya 12y ago
  I don't get the "rebasing sucks" argument about why git is bad, at all. Most professional arenas will have a source control best practices document, how hard is it to say "no rebasing allowed"? Just because a feature exists does not mean it has to be used or even should ever be used.
- jackweirdy 12y ago
  I follow your rule, but with a slight tweak - only rebase on non-master branches, and before having pushed. After that it's out the window
opendais 12y ago
> o Git has been bundled with code review systems like Gerrit which encourages developers to rebase heavily to create a false history presenting themselves as fantasy 10X programmers who don't make mistakes, debug, engage in trial and error, or all the other things developers actually do. When a bug does slip through as if often does despite the supposed quality-control benefits of code review, then reconstructing what happened from the rebased "history" can be a nightmare. I've never seen anyone do that in a professional environment. My coworkers laugh at me because my most common commit text? "fixed XYZ??" Sometimes, multiple times in a row. > o A fanatical, cult-like following apparently mesmerized by Linus Torvalds that is unable to recognize or acknowledge the many obvious problems with Git. I think this stems from hanging out in online forums. Git is flawed. Git's virtues are the size of its ecosystem, the fact it is distributed, and the fact it is useful to some people.

SeoxyS 12y ago

Sounds like you were bit by rebasing, rather than by git itself. Yes, the API is large and complex. But git itself is easy to learn, and extremely powerful. Whatever situation you might have gotten yourself into, git probably has a good way to handle it. There's one rule I abide by, which makes my git usage sane: no rebasing. Everything stays in the history, and there's no reason to squash commits into one giant context-less commit. The only common case in which rebasing is valuable is in getting rid of meaningless commits constantly merging the latest master into a feature branch.

cozuya 12y ago
I don't get the "rebasing sucks" argument about why git is bad, at all. Most professional arenas will have a source control best practices document, how hard is it to say "no rebasing allowed"? Just because a feature exists does not mean it has to be used or even should ever be used.
jackweirdy 12y ago
I follow your rule, but with a slight tweak - only rebase on non-master branches, and before having pushed. After that it's out the window

opendais 12y ago

> o Git has been bundled with code review systems like Gerrit which encourages developers to rebase heavily to create a false history presenting themselves as fantasy 10X programmers who don't make mistakes, debug, engage in trial and error, or all the other things developers actually do. When a bug does slip through as if often does despite the supposed quality-control benefits of code review, then reconstructing what happened from the rebased "history" can be a nightmare. I've never seen anyone do that in a professional environment. My coworkers laugh at me because my most common commit text? "fixed XYZ??" Sometimes, multiple times in a row. > o A fanatical, cult-like following apparently mesmerized by Linus Torvalds that is unable to recognize or acknowledge the many obvious problems with Git. I think this stems from hanging out in online forums. Git is flawed. Git's virtues are the size of its ecosystem, the fact it is distributed, and the fact it is useful to some people.