4 ms·

Git is overrated. No, it's pretty widely regarded as a good, but not perfect, DVCS. Complex, confusing terminology including multiple non-obvious names for va

Git is overrated. No, it's pretty widely regarded as a good, but not perfect, DVCS. Complex, confusing terminology including multiple non-obvious names for various components. DVCS is inherently complex. Git's terminology might possibly be improved, but it's not really all that bad. It just requires a bit of learning. Huge number, about 148, of commands with many sub-commands that often do non-obvious, even unrelated things. That's the same point. There are a lot of tasks to accomplish in a DVCS, which requires a lot of commands. You don't have to use these: they just have to be available for those that need them. git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system. Rebasing allows a user to rewrite history such that it makes sense, in terms of the changesets applicable to the repository as a whole. That's not a subversion - it's intentional. Git has been … reconstructing what happened from the rebased "history" can be a nightmare. This is a workflow problem, not a tool problem. 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. This is the same thing as your first two points. These command all do similar, overlapping tasks, but are all useful in different circumstances. A supposed virtue of git is that it makes it extremely easy to create "branches." This often leads to a proliferation of branches Yes, and git's lightweight branches are great. I have never been in a situation where this causes problems; if you are encountering those, then you have a problem with workflow. Don't blame the tools. Cryptic hexadecimal SHA for identifying commits instead of sequential numbers for individual files I don't even know how you think that would work in the context of a DVCS. * These many flaws in git and its command line interface have resulted in a proliferation of third-party add-on tools* That "third party tools exist" is not a valid complaint. 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. Git can be used in almost the same fashion as SVN by learning that a couple of commands have different names. A fanatical, cult-like following apparently mesmerized by Linus Torvalds that is unable to recognize or acknowledge the many obvious problems with Git. Not that I've observed. Git is popular because it's quite good - equivalent or better to other DVCS systems. That's not a cult of personality. tldr; git isn't that bad - it's quite complex, and it's a powerful tool that relies on users to be responsible. But that's not really a bad thing, as far as I'm concerned. It's certainly better than subversion for every project I've worked on.

NumberSix 12y ago
Note: Overrated means something is widely regarded as good ... but isn't. A version control system should be very simple, hardly noticeable like the original RCS. 1. checkin the current version after each change. 2. if a serious problem is encountered, checkout an earlier version to see what happened and find when and where bug was introduced. That is about it and RCS does it with a handful of commands. The obvious question is why can't a distributed version control system like Git hide most of the complexity of managing a network of distributed repositories from the developer, at most adding a few network commands, e.g. clone, pull, push? Where do the 148 commands come from? Why not just use the standard RCS command line interface with a small number of additions and let the back end deal with the distributed repositories? Extend the RCS/CVS/SVN sequential ids with a suffix to identify something like repository/branch to keep track of local changes? Sincerely, Bit by Git
- brandonbloom 12y ago
  A version control system should be [...] hardly noticeable And that right there is the fundamental philosophical difference which is preventing you from understanding why people like Git. It's not just a revision control system, it's a tool for crafting code and patches. Git is a fundamental part of my workflow for how I write code locally, even without contributors, and beyond backup/undo use-cases. However, with contributors, patches count as communication, and tools to help me craft those patches effectively were missing from my toolbox prior to Git.
  - NumberSix 12y ago
    I think I have a good understanding of why people like Git. I question whether they should. In my experience, the time to learn Git for people unfamiliar with it is significantly larger than for any RCS-style version control system including Subversion which is probably the most complicated RCS-style version control system. Similarly, even if you are proficient with Git, on average it takes significantly longer to use Git to do the same things as an RCS style version control system. This is true even if you use Git in a very simple way. If you use it in one of the very complex ways like the Android project/Git/Gerrit/Jenkins morass, it will take a lot longer. This time is a real cost to a business or an open-source project or what have you. Simplicity is often faster, cheaper, and better. I argue that it is more effective in a team project to share the actual history of the development in a shared development branch -- warts and all. Production and release candidates -- the works of art that you are trying to create -- can be tagged or identified in some other way. Bit by Git

NumberSix 12y ago

Note: Overrated means something is widely regarded as good ... but isn't. A version control system should be very simple, hardly noticeable like the original RCS. 1. checkin the current version after each change. 2. if a serious problem is encountered, checkout an earlier version to see what happened and find when and where bug was introduced. That is about it and RCS does it with a handful of commands. The obvious question is why can't a distributed version control system like Git hide most of the complexity of managing a network of distributed repositories from the developer, at most adding a few network commands, e.g. clone, pull, push? Where do the 148 commands come from? Why not just use the standard RCS command line interface with a small number of additions and let the back end deal with the distributed repositories? Extend the RCS/CVS/SVN sequential ids with a suffix to identify something like repository/branch to keep track of local changes? Sincerely, Bit by Git

brandonbloom 12y ago
A version control system should be [...] hardly noticeable And that right there is the fundamental philosophical difference which is preventing you from understanding why people like Git. It's not just a revision control system, it's a tool for crafting code and patches. Git is a fundamental part of my workflow for how I write code locally, even without contributors, and beyond backup/undo use-cases. However, with contributors, patches count as communication, and tools to help me craft those patches effectively were missing from my toolbox prior to Git.
- NumberSix 12y ago
  I think I have a good understanding of why people like Git. I question whether they should. In my experience, the time to learn Git for people unfamiliar with it is significantly larger than for any RCS-style version control system including Subversion which is probably the most complicated RCS-style version control system. Similarly, even if you are proficient with Git, on average it takes significantly longer to use Git to do the same things as an RCS style version control system. This is true even if you use Git in a very simple way. If you use it in one of the very complex ways like the Android project/Git/Gerrit/Jenkins morass, it will take a lot longer. This time is a real cost to a business or an open-source project or what have you. Simplicity is often faster, cheaper, and better. I argue that it is more effective in a team project to share the actual history of the development in a shared development branch -- warts and all. Production and release candidates -- the works of art that you are trying to create -- can be tagged or identified in some other way. Bit by Git