7 ms·

Why Git sucks?

43 points by lelf 12y ago

tonetheman 12y ago
I think my main problem with git (though I use it) is that things that should be simple are mind numbing hard. At 2:00am when I working, having to read pages and pages to decide if git pull is the right thing is just painful. I never felt that type of pain with SVN, it more or less just maps to directories. To each his own I wish there was the right way to use git in 50 words or less. If I need to read a book to correctly use it ... grrrrrrr.
- thrush 12y ago
  Some people like git pull, but I prefer git fetch. This gets all's the history from the remote repo without applying any changes. Then you can run something like 'git rebase -i origin/master' which is where I think git can really shine. There is an excellent link out there that explains git in layman's terms. I think it's called git for hackers or something of the sort. It's much easier than the docs in my opinion.
  - SDGT 12y ago
    Best practices are to not use pull unless you certainly know you should. Things should be fetched then merged with two separate commands.
    - gizmo686 12y ago
      Pulling is equivelent to doing a fetch then a merge. Unless you plan on doing something between the two steps (like inspecting FETCH_HEAD yourself), then there is no advantage to not simply pulling. Of course, if (like thrush) you do not plan on doing a merge, then you will need to do the fetch manually and do what you do want to do. Although, git pull does have a --rebase option, but I am not sure if you can pass the -i flag to it. Having taught people how to use git, I found that it is easier to not show them the pull command until they are used to doing fetch && merge.
  - mitchty 12y ago
    Can just git pull --rebase too instead of fetch/rebase.
- clintonb 12y ago
  What!? The scenario you described doesn't make much sense. Why would you need to read pages to determine if git pull is the correct command to use?
  - georgemcbay 12y ago
    Partly because the terminology tends to be slightly different than other source code control systems use. Also partly because if you do any research on git usage patterns you will find like 6 totally different ways you can use git to do roughly what you used to do in svn, and any one of the options you choose of those will have pages and pages of blog posts explaining why doing it that way is stupid and wrong and you should really do it in this other of the 6 ways, with no real authoritative explanation of when you should use which pattern. The end result is a situation where you have to learn a lot about how git works internally to actually have an idea if how you are using it makes sense or not in relation to your project. git isn't nearly opinionated enough for simple usage patterns, IMO. I like the flexibility it offers but it would be nice for new adopters if it were more hidden and there was a more obvious "happy n00b path" to take when first starting with it for the majority of projects that don't have the sort of distributed development challenges that the linux kernel does. Note: I'm not the OP and I'm really comfortable with git now, but I've been where OP is and totally understand.
- jerf 12y ago
  "I never felt that type of pain with SVN, it more or less just maps to directories." Ironically, that's one of my major fatal objections to SVN, the way it casually encourages developers to have a code checkout that doesn't actually exist in the source repo, as you check out various versions in various subdirectories without even thinking about it if you aren't careful. Back in my SVN days I lost track of how many times it worked on somebody else's box and not on mine, because one or the other of us (or both!) had a checkout that didn't actually represent any particular revision. "Well, don't do that then!" Of course not, but A: I can still be bitten by other developers doing it and B: SVN really, really affords this. By accident, sure, but it is afforded nonetheless. In fact in a lot of ways SVN vs. Git reminds me of static vs. dynamic typing... many of the "easier" things that SVN does are also wrong, and many of the things that people are objecting to about git are actually the underlying model being correct, and refusing to be wrong. I don't mean the UI, which is sort of dodgy, sure, but the underlying model. (Git submodules are sort of that way... in many ways, the difficulties in using them are reflective of the fact that correctly embedding one source code repo in another is actually fundamentally hard, and anything that makes it easy is probably just glossing over some fundamental problems. It is probably possible to make it easier, but if it has been made easy, one should immediately be very suspicious.)
johnchristopher 12y ago
> I can't also see any practical solution for a separation of concerns. Some users could e.g. work only on translation and need only to checkout XML files and push them back to the repo. With Git, that would have to be a separate repo. I am far from being good with Git yet but why couldn't the translator simply branch out and only merge back his XML files ?
- rst 12y ago
  Perhaps the issue is that there's no technical barrier to them messing around with something else, perhaps by accident. (And if you try to deal with this by playing around with filesystem-level write positions in the repo, then they can't pull down new versions of the rest of the project either.) The only really clean solution is to use submodules (or the newer variation on the theme, git subtree). But those aren't entirely smooth either.
  - bluecalm 12y ago
    The idea of Git is that everybody has their own local copy of a whole repo so it doesn't really matter what they do with it or if they mess it up. If other people want to merge the changes to their repos they will see what was changed and what wasn't so if you get pull request from "XML only guy" you just verify if only XML files were changed. You seem to think about it in terms of one master which isn't Git way.
    - rst 12y ago
      And you're thinking about a workflow in which no one ever uses "git push". If most devs do, and "the XML guy" can't (because someone else needs to look over his commits), that's a headache, which could be solved technically. Come to think of it, it could be solved technically even with git -- the XML guy's repo gets a pre-commit hook that verifies that he's committing changes only to the files he's allowed to edit. (We're now requiring him not to mess with that hook, but if that's a problem, maybe they shouldn't have source code access at all. The point is that now a tool is doing the checks, which frees up the humans for things that really do require human judgment.)
eknkc 12y ago
Used both SVN and GIT on different types of projects. Gotta admit, it's been a little harder to get used to GIT. It has a more complex interface and ways of doing things. However, it feels like comparing SVN to GIT is like comparing horses to automobiles at this point.. Yes, a horse can heal minor damages without a mechanic, your car can't. And it can swim if need arises, good luck with a car on that. Woudn't choose a horse for anything serious though. Maybe for fun and sports.
- jackweirdy 12y ago
  Nitpick: It's just Git, it's not an acronym. I agree git has a more complex interface - I think I've read it described as "not quite user-hostile, but only expert-friendly", which I think fits. That said, I think the model of how commits work is far more intuitive than anything else I've come across. A commit is just a diff and a pointer to the commit that came before it, and a branch is just a pointer to a particular commit.
  - blktiger 12y ago
    Technically, a commit is a _snapshot_, not a diff.
  - LukeShu 12y ago
    Nitpick: A commit is not a diff, it is the entire tree. Any diffs you see are computed, not stored. You can export a commit as a diff+pointer-to-prev-commit, but when git imports it, it gets turned back into a full tree.
    - jackweirdy 12y ago
      That's true. I simplified for the sake of not delving too far into the details, because it makes sense at the smaller level. It's also true that a commit isn't always just one pointer to the commit that came before it, in a merge there are two pointers, from commit_head and merge_head
- alexcroox 12y ago
undata 12y ago
These are extremely superficial reasons to criticize git, leading me to believe that the author knows very little about git internals. I'll take the first critique and leave the second to someone else... You can't pull a portion of the repo because the current state of the repo is built from the tree of commit diffs... This and the fact that git itself is a hash database leads to very efficient use of space. If you want a single folder within a repo, why isn't that folder its own repo? Between that, the passive aggressive ;-) and the unfortunate advocacy of SVN... ugh.
- danielweber 12y ago
  leading me to believe that the author knows very little about git internals Needing to know about the internals of git is a flaw of git, not a feature.
  - undata 12y ago
    Why would you use a tool you don't understand? What if it breaks?
- rst 12y ago
  He's saying that "pulling a portion of the repo" is one of his use cases, and not being able to do that gets in his way. Pointing out technical reasons why git doesn't do the job he wants doesn't make it useful for him, it just points out why the problem is hard to fix.
  - eropple 12y ago
    "Doctor, it hurts when I do this" does have an answer of its own.
    - Anderkent 12y ago
      Is the answer 'use a better tool'?
    - jsmeaton 12y ago
NumberSix 12y ago
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
SDGT 12y ago
> Impractical for single repository of libraries Submodules? I actually think an entire repo of libraries is the wrong way to go. With the git model, we have however many repos acting as the source for these libraries. This repository that contains all of these submodules can then be the arbiter of which version should be included in the release. > Yes, some will say - but this is good - centralization is bad... Well, it depends. If you can spend time to figure out who is who, then it will work for you. And this problem doesn't exist with SVN? Sure, maybe if you are the sole publisher of all these libraries it might be ok, but with most real world examples, there exists multiple contributors. Now they need to go through you when there needs to be a specific update to that library. With git, the maintainer of the repo of libraries(submodules) just updates the specific submodule to whatever release works for their tastes. Most of these complaints sound like an SVN user having some pain when trying to think in git.
idunning 12y ago
A benefit of git, for which I can forgive a lot of git's flaws, that was not mentioned in the conclusion is the light-weight branching. The ability to quickly make a branch, experiment, branch off that, merge back, cherrypick commits from another branch, etc. makes me more efficient by spending less time worrying about affecting stable code with experimental changes.
- jdjb 12y ago
  Yup this is exactly it. For developers fluent in git, it is a very real part of their development cycle (branching, rebasing, etc). What I've seen of most SVN (and going back to CVS) is that their SCM is more or less just an archiving tool. A place after you've done all your hard work you use it as a fancy rsync tool to back it up. I don't see a lot of SVN users making svn the same part of their workflow the way git devs do. Maybe it's just the developers I work with though.
ereyes01 12y ago
re: the "Impractical for single repository of libraries" section... The author seems to think the only way to manage many different plugins is to split them into different repos: "If you have e.g. 100 plugins, you should have 100 repos." Many times, 1 repo works perfectly fine for 100 plugins. As for wanting to only work with a subset of the files, the way git wants you to do that is to branch and change the subset you want to change (someone else has already pointed that out too here in the comments). What to split into how many repos is often a very subjective call, and depends on team, respository size, and workflow. A real-world example where 1 repo works perfectly fine is the Linux kernel. Within one repo, you have all sorts of drivers for all sorts of hardware, and you have arch-specific support for a dizzying amount of processors and variants. The repo takes a while to clone the first time since it's kind of big, but thereafter works perfectly fine as you whizz between branches and jump between tags. On some level, I understand the author's frustration with git, since it's quite a paradigm shift from centralized repos like Subversion. I made that shift myself once, and at first I didn't like being forced to play by git's rules of the universe (or more correctly, the DVCS rules of the universe). I have come to deeply appreciate those new rules over time. There are, in fact, valid criticisms of git. One that comes to mind is the complexity and amount of operations... looks like others have already commented on this sort of criticism.
damm 12y ago
Sounds like the author has a workflow problem here. Most of the reasons given of why Git sucks could be from the OP's inability to adapt their workflow. SCM is a matter of choice; there is no right or wrong answer and people need to get over being right.
- isxek 12y ago
  > SCM is a matter of choice; there is no right or wrong answer That really sums it up. The right answer comes from seeing what you need and using whatever tool fits the job.
- deleted 12y ago
  [deleted]
Walkman 12y ago
> In Git, you can checkout neither a single folder nor a file. Yes, you can. It's called sparse checkout[1] and not that hard. Also, you can subtree merge[2][3] directories back and forth preserving all the history and merging back if you wish (cutting a directory out of the repository to a separate one and putting it back). It's pretty easy to do in git>2.0 because there is a builtin subtree command[4] for it. [1]: https://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout https://www.kernel.org/pub/software/scm/git/docs/git-read-tr... [2]: https://help.github.com/articles/about-git-subtree-merges https://help.github.com/articles/about-git-subtree-merges [3]: http://git-scm.com/book/en/Git-Tools-Subtree-Merging http://git-scm.com/book/en/Git-Tools-Subtree-Merging [4]: https://news.ycombinator.com/item?id=3926683 https://news.ycombinator.com/item?id=3926683
- manojlds 12y ago
  The actual meaning here is "clone" a single folder or file, not checkout.
  - Walkman 12y ago
    There is no practical difference. Yes, you clone and have the whole repository on the disk, but after a sparse checkout you only have to deal with the files you are interested in. The only problem can be with Facebook-sized repositories, but I believe in modularizing that big of a system instead of storing everything in one vast repository.
imcn 12y ago
Use Magit, it's great.
aikah 12y ago
It's impressive how a software became a defacto standard when things like mercurial or SVN existed long before it.It's not just hype or Github,though it helps.It's the distributed nature of the software that makes it powerfull, also the fact that git itself is more like a protocol than a piece of software.But git dont work for every use cases though( big binary blobs ),so there is still room on the market for such cases.
- isxek 12y ago
  Mercurial was created around the same time as Git was (April 2005), and both projects were announced in the Linux kernel mailing list. You're probably referring to Bitkeeper, which did exist (and was available commercially) before these new VCS's.
ramnes 12y ago
> I also see no way this would work for branching. You would have to change all your submodules. `git submodule foreach`
tsmash 12y ago
You could only come up with two things that no one ever runs in to? Git has tons of problems but neither of these are important problems.
Smudge 12y ago
I'm a fan of using the right tool for the job. If you can't use git effectively or it just doesn't fit into your workflow, then, hey, don't use it. But, having used both, I'd actually like to know... Why are these things (that the author is claiming git can't do) so important? For instance, is checking out a partial tree ever necessary? Is it that you'd want more granularity over what subsets of the repo you are storing locally? Is it that you don't want to have to set up a bunch of (sub-)repositories? I ask because... I once worked on a codebase that was so absurdly huge most of us couldn't store it all on disk at once. And it sucked. Hard. I WISH it had been started as a bunch of distinct submodules, with extension points baked into the core build system so it would be easy to add/remove sections of the codebase. But the product predated git. And SVN for that matter. (Granted, the majority of the issues we suffered -- nightmarishly complex build systems, lack of transparency into what changes are being made, a bottleneck of devs lining up to commit changes -- were caused by process issues, not source control. But the source control did absolutely nothing to help either.) I really understand the frustration when it comes to git. It took me a LONG time to wrap my head around why it works the way it does, because I wanted/expected it to work like SVN, where the repository is like a giant tree of files reflecting exactly what I see on disk, with different branches of code getting their own branch of the tree. Instead, git was this concise, magical pile of data structures that somehow kept causing me to break things whenever I strayed too far from a basic commit & push workflow. But then I changed jobs a couple times. And, for some reason, I no longer found git a huge pain. In part because it just started becoming more natural and I knew what kinds of things to avoid, but also because I decided to sit down and really learn what I was doing. For one thing, I began making more active use of rebasing. Initially so I didn't need a ton of useless merge commits to keep up-to-date with the master branch, but eventually as a way of tidying up my work on a feature branch (i.s. squash, reorder, amend, etc) to make the set of changes concise and easy to follow. When working locally on a new feature branch, my commit log went from looking like this: > okay one more try at part A [tests pass] > fixing typo [tests pass] > one last thing for part C [tests fail] > part B bugfix [tests pass] > fixing bug in part C [tests fail] > finishing part B [tests fail] > trying this again (feature A) [tests fail] > part C, work in progress [tests fail] > part A, I think [tests fail] ... To this (more or less): > part C [tests pass] > part A (final implementation) [tests pass] > part B [tests pass] > part A (initial implementation) [tests pass] ... Depending on who you are, you'll either love that, or you'll scream at my lying, revisionist git log before wrenching out your eyes and hurling yourself out a window. But, for me, for the team I was working with, and for the codebase I was working on, it worked WONDERFULLY. I found myself feeling like I really controlled the readability of my changes. Each of those commits could be submitted individually for code review with no problems, and even though I was wiping out a ton of minor changes, I could still preserve a record of alternate implementations in case we wanted to refer to them later. Anyway, this post has become a long ramble. But, suffice it to say, I've found git to be very freeing. I just had to give up any expectations about how the process would work, and let myself start forming a new process around the power and flexibility that git offers. I believe I could say the same for mercurial (though I don't have much experience on it). And I don't think I can say as much for SVN, though I'm sure it does have a few advantages. And if you're workflow really can't change... SVN certainly works for what it is. It's just not something I'd ever like to go back to.
keerthiko 12y ago
I just wanted to say that even if you don't read this article, this discussion here on HN is very enlightening for people who tend to only use a small subset of git operations in their day-to-day small-team dev tasks (like me).

43 points by lelf 12y ago

I think my main problem with git (though I use it) is that things that should be simple are mind numbing hard. At 2:00am when I working, having to read pages and pages to decide if git pull is the right thing is just painful. I never felt that type of pain with SVN, it more or less just maps to directories. To each his own I wish there was the right way to use git in 50 words or less. If I need to read a book to correctly use it ... grrrrrrr.

thrush 12y ago
Some people like git pull, but I prefer git fetch. This gets all's the history from the remote repo without applying any changes. Then you can run something like 'git rebase -i origin/master' which is where I think git can really shine. There is an excellent link out there that explains git in layman's terms. I think it's called git for hackers or something of the sort. It's much easier than the docs in my opinion.
- SDGT 12y ago
  Best practices are to not use pull unless you certainly know you should. Things should be fetched then merged with two separate commands.
  - gizmo686 12y ago
    Pulling is equivelent to doing a fetch then a merge. Unless you plan on doing something between the two steps (like inspecting FETCH_HEAD yourself), then there is no advantage to not simply pulling. Of course, if (like thrush) you do not plan on doing a merge, then you will need to do the fetch manually and do what you do want to do. Although, git pull does have a --rebase option, but I am not sure if you can pass the -i flag to it. Having taught people how to use git, I found that it is easier to not show them the pull command until they are used to doing fetch && merge.
- mitchty 12y ago
  Can just git pull --rebase too instead of fetch/rebase.
clintonb 12y ago
What!? The scenario you described doesn't make much sense. Why would you need to read pages to determine if git pull is the correct command to use?
- georgemcbay 12y ago
  Partly because the terminology tends to be slightly different than other source code control systems use. Also partly because if you do any research on git usage patterns you will find like 6 totally different ways you can use git to do roughly what you used to do in svn, and any one of the options you choose of those will have pages and pages of blog posts explaining why doing it that way is stupid and wrong and you should really do it in this other of the 6 ways, with no real authoritative explanation of when you should use which pattern. The end result is a situation where you have to learn a lot about how git works internally to actually have an idea if how you are using it makes sense or not in relation to your project. git isn't nearly opinionated enough for simple usage patterns, IMO. I like the flexibility it offers but it would be nice for new adopters if it were more hidden and there was a more obvious "happy n00b path" to take when first starting with it for the majority of projects that don't have the sort of distributed development challenges that the linux kernel does. Note: I'm not the OP and I'm really comfortable with git now, but I've been where OP is and totally understand.
jerf 12y ago
"I never felt that type of pain with SVN, it more or less just maps to directories." Ironically, that's one of my major fatal objections to SVN, the way it casually encourages developers to have a code checkout that doesn't actually exist in the source repo, as you check out various versions in various subdirectories without even thinking about it if you aren't careful. Back in my SVN days I lost track of how many times it worked on somebody else's box and not on mine, because one or the other of us (or both!) had a checkout that didn't actually represent any particular revision. "Well, don't do that then!" Of course not, but A: I can still be bitten by other developers doing it and B: SVN really, really affords this. By accident, sure, but it is afforded nonetheless. In fact in a lot of ways SVN vs. Git reminds me of static vs. dynamic typing... many of the "easier" things that SVN does are also wrong, and many of the things that people are objecting to about git are actually the underlying model being correct, and refusing to be wrong. I don't mean the UI, which is sort of dodgy, sure, but the underlying model. (Git submodules are sort of that way... in many ways, the difficulties in using them are reflective of the fact that correctly embedding one source code repo in another is actually fundamentally hard, and anything that makes it easy is probably just glossing over some fundamental problems. It is probably possible to make it easier, but if it has been made easy, one should immediately be very suspicious.)

johnchristopher 12y ago

> I can't also see any practical solution for a separation of concerns. Some users could e.g. work only on translation and need only to checkout XML files and push them back to the repo. With Git, that would have to be a separate repo. I am far from being good with Git yet but why couldn't the translator simply branch out and only merge back his XML files ?

rst 12y ago
Perhaps the issue is that there's no technical barrier to them messing around with something else, perhaps by accident. (And if you try to deal with this by playing around with filesystem-level write positions in the repo, then they can't pull down new versions of the rest of the project either.) The only really clean solution is to use submodules (or the newer variation on the theme, git subtree). But those aren't entirely smooth either.
- bluecalm 12y ago
  The idea of Git is that everybody has their own local copy of a whole repo so it doesn't really matter what they do with it or if they mess it up. If other people want to merge the changes to their repos they will see what was changed and what wasn't so if you get pull request from "XML only guy" you just verify if only XML files were changed. You seem to think about it in terms of one master which isn't Git way.
  - rst 12y ago
    And you're thinking about a workflow in which no one ever uses "git push". If most devs do, and "the XML guy" can't (because someone else needs to look over his commits), that's a headache, which could be solved technically. Come to think of it, it could be solved technically even with git -- the XML guy's repo gets a pre-commit hook that verifies that he's committing changes only to the files he's allowed to edit. (We're now requiring him not to mess with that hook, but if that's a problem, maybe they shouldn't have source code access at all. The point is that now a tool is doing the checks, which frees up the humans for things that really do require human judgment.)

eknkc 12y ago

Used both SVN and GIT on different types of projects. Gotta admit, it's been a little harder to get used to GIT. It has a more complex interface and ways of doing things. However, it feels like comparing SVN to GIT is like comparing horses to automobiles at this point.. Yes, a horse can heal minor damages without a mechanic, your car can't. And it can swim if need arises, good luck with a car on that. Woudn't choose a horse for anything serious though. Maybe for fun and sports.

jackweirdy 12y ago
Nitpick: It's just Git, it's not an acronym. I agree git has a more complex interface - I think I've read it described as "not quite user-hostile, but only expert-friendly", which I think fits. That said, I think the model of how commits work is far more intuitive than anything else I've come across. A commit is just a diff and a pointer to the commit that came before it, and a branch is just a pointer to a particular commit.
- blktiger 12y ago
  Technically, a commit is a _snapshot_, not a diff.
- LukeShu 12y ago
  Nitpick: A commit is not a diff, it is the entire tree. Any diffs you see are computed, not stored. You can export a commit as a diff+pointer-to-prev-commit, but when git imports it, it gets turned back into a full tree.
  - jackweirdy 12y ago
    That's true. I simplified for the sake of not delving too far into the details, because it makes sense at the smaller level. It's also true that a commit isn't always just one pointer to the commit that came before it, in a merge there are two pointers, from commit_head and merge_head
alexcroox 12y ago

undata 12y ago

These are extremely superficial reasons to criticize git, leading me to believe that the author knows very little about git internals. I'll take the first critique and leave the second to someone else... You can't pull a portion of the repo because the current state of the repo is built from the tree of commit diffs... This and the fact that git itself is a hash database leads to very efficient use of space. If you want a single folder within a repo, why isn't that folder its own repo? Between that, the passive aggressive ;-) and the unfortunate advocacy of SVN... ugh.

danielweber 12y ago
leading me to believe that the author knows very little about git internals Needing to know about the internals of git is a flaw of git, not a feature.
- undata 12y ago
  Why would you use a tool you don't understand? What if it breaks?
rst 12y ago
He's saying that "pulling a portion of the repo" is one of his use cases, and not being able to do that gets in his way. Pointing out technical reasons why git doesn't do the job he wants doesn't make it useful for him, it just points out why the problem is hard to fix.
- eropple 12y ago
  "Doctor, it hurts when I do this" does have an answer of its own.
  - Anderkent 12y ago
    Is the answer 'use a better tool'?
  - jsmeaton 12y ago

NumberSix 12y ago

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

SDGT 12y ago

> Impractical for single repository of libraries Submodules? I actually think an entire repo of libraries is the wrong way to go. With the git model, we have however many repos acting as the source for these libraries. This repository that contains all of these submodules can then be the arbiter of which version should be included in the release. > Yes, some will say - but this is good - centralization is bad... Well, it depends. If you can spend time to figure out who is who, then it will work for you. And this problem doesn't exist with SVN? Sure, maybe if you are the sole publisher of all these libraries it might be ok, but with most real world examples, there exists multiple contributors. Now they need to go through you when there needs to be a specific update to that library. With git, the maintainer of the repo of libraries(submodules) just updates the specific submodule to whatever release works for their tastes. Most of these complaints sound like an SVN user having some pain when trying to think in git.

idunning 12y ago

A benefit of git, for which I can forgive a lot of git's flaws, that was not mentioned in the conclusion is the light-weight branching. The ability to quickly make a branch, experiment, branch off that, merge back, cherrypick commits from another branch, etc. makes me more efficient by spending less time worrying about affecting stable code with experimental changes.

jdjb 12y ago
Yup this is exactly it. For developers fluent in git, it is a very real part of their development cycle (branching, rebasing, etc). What I've seen of most SVN (and going back to CVS) is that their SCM is more or less just an archiving tool. A place after you've done all your hard work you use it as a fancy rsync tool to back it up. I don't see a lot of SVN users making svn the same part of their workflow the way git devs do. Maybe it's just the developers I work with though.

ereyes01 12y ago

re: the "Impractical for single repository of libraries" section... The author seems to think the only way to manage many different plugins is to split them into different repos: "If you have e.g. 100 plugins, you should have 100 repos." Many times, 1 repo works perfectly fine for 100 plugins. As for wanting to only work with a subset of the files, the way git wants you to do that is to branch and change the subset you want to change (someone else has already pointed that out too here in the comments). What to split into how many repos is often a very subjective call, and depends on team, respository size, and workflow. A real-world example where 1 repo works perfectly fine is the Linux kernel. Within one repo, you have all sorts of drivers for all sorts of hardware, and you have arch-specific support for a dizzying amount of processors and variants. The repo takes a while to clone the first time since it's kind of big, but thereafter works perfectly fine as you whizz between branches and jump between tags. On some level, I understand the author's frustration with git, since it's quite a paradigm shift from centralized repos like Subversion. I made that shift myself once, and at first I didn't like being forced to play by git's rules of the universe (or more correctly, the DVCS rules of the universe). I have come to deeply appreciate those new rules over time. There are, in fact, valid criticisms of git. One that comes to mind is the complexity and amount of operations... looks like others have already commented on this sort of criticism.

damm 12y ago

Sounds like the author has a workflow problem here. Most of the reasons given of why Git sucks could be from the OP's inability to adapt their workflow. SCM is a matter of choice; there is no right or wrong answer and people need to get over being right.

isxek 12y ago
> SCM is a matter of choice; there is no right or wrong answer That really sums it up. The right answer comes from seeing what you need and using whatever tool fits the job.
deleted 12y ago
[deleted]

Walkman 12y ago

> In Git, you can checkout neither a single folder nor a file. Yes, you can. It's called sparse checkout[1] and not that hard. Also, you can subtree merge[2][3] directories back and forth preserving all the history and merging back if you wish (cutting a directory out of the repository to a separate one and putting it back). It's pretty easy to do in git>2.0 because there is a builtin subtree command[4] for it. [1]: https://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout https://www.kernel.org/pub/software/scm/git/docs/git-read-tr... [2]: https://help.github.com/articles/about-git-subtree-merges https://help.github.com/articles/about-git-subtree-merges [3]: http://git-scm.com/book/en/Git-Tools-Subtree-Merging http://git-scm.com/book/en/Git-Tools-Subtree-Merging [4]: https://news.ycombinator.com/item?id=3926683 https://news.ycombinator.com/item?id=3926683

manojlds 12y ago
The actual meaning here is "clone" a single folder or file, not checkout.
- Walkman 12y ago
  There is no practical difference. Yes, you clone and have the whole repository on the disk, but after a sparse checkout you only have to deal with the files you are interested in. The only problem can be with Facebook-sized repositories, but I believe in modularizing that big of a system instead of storing everything in one vast repository.

imcn 12y ago

Use Magit, it's great.

aikah 12y ago

It's impressive how a software became a defacto standard when things like mercurial or SVN existed long before it.It's not just hype or Github,though it helps.It's the distributed nature of the software that makes it powerfull, also the fact that git itself is more like a protocol than a piece of software.But git dont work for every use cases though( big binary blobs ),so there is still room on the market for such cases.

isxek 12y ago
Mercurial was created around the same time as Git was (April 2005), and both projects were announced in the Linux kernel mailing list. You're probably referring to Bitkeeper, which did exist (and was available commercially) before these new VCS's.

ramnes 12y ago

> I also see no way this would work for branching. You would have to change all your submodules. `git submodule foreach`

tsmash 12y ago

You could only come up with two things that no one ever runs in to? Git has tons of problems but neither of these are important problems.

Smudge 12y ago

I'm a fan of using the right tool for the job. If you can't use git effectively or it just doesn't fit into your workflow, then, hey, don't use it. But, having used both, I'd actually like to know... Why are these things (that the author is claiming git can't do) so important? For instance, is checking out a partial tree ever necessary? Is it that you'd want more granularity over what subsets of the repo you are storing locally? Is it that you don't want to have to set up a bunch of (sub-)repositories? I ask because... I once worked on a codebase that was so absurdly huge most of us couldn't store it all on disk at once. And it sucked. Hard. I WISH it had been started as a bunch of distinct submodules, with extension points baked into the core build system so it would be easy to add/remove sections of the codebase. But the product predated git. And SVN for that matter. (Granted, the majority of the issues we suffered -- nightmarishly complex build systems, lack of transparency into what changes are being made, a bottleneck of devs lining up to commit changes -- were caused by process issues, not source control. But the source control did absolutely nothing to help either.) I really understand the frustration when it comes to git. It took me a LONG time to wrap my head around why it works the way it does, because I wanted/expected it to work like SVN, where the repository is like a giant tree of files reflecting exactly what I see on disk, with different branches of code getting their own branch of the tree. Instead, git was this concise, magical pile of data structures that somehow kept causing me to break things whenever I strayed too far from a basic commit & push workflow. But then I changed jobs a couple times. And, for some reason, I no longer found git a huge pain. In part because it just started becoming more natural and I knew what kinds of things to avoid, but also because I decided to sit down and really learn what I was doing. For one thing, I began making more active use of rebasing. Initially so I didn't need a ton of useless merge commits to keep up-to-date with the master branch, but eventually as a way of tidying up my work on a feature branch (i.s. squash, reorder, amend, etc) to make the set of changes concise and easy to follow. When working locally on a new feature branch, my commit log went from looking like this: > okay one more try at part A [tests pass] > fixing typo [tests pass] > one last thing for part C [tests fail] > part B bugfix [tests pass] > fixing bug in part C [tests fail] > finishing part B [tests fail] > trying this again (feature A) [tests fail] > part C, work in progress [tests fail] > part A, I think [tests fail] ... To this (more or less): > part C [tests pass] > part A (final implementation) [tests pass] > part B [tests pass] > part A (initial implementation) [tests pass] ... Depending on who you are, you'll either love that, or you'll scream at my lying, revisionist git log before wrenching out your eyes and hurling yourself out a window. But, for me, for the team I was working with, and for the codebase I was working on, it worked WONDERFULLY. I found myself feeling like I really controlled the readability of my changes. Each of those commits could be submitted individually for code review with no problems, and even though I was wiping out a ton of minor changes, I could still preserve a record of alternate implementations in case we wanted to refer to them later. Anyway, this post has become a long ramble. But, suffice it to say, I've found git to be very freeing. I just had to give up any expectations about how the process would work, and let myself start forming a new process around the power and flexibility that git offers. I believe I could say the same for mercurial (though I don't have much experience on it). And I don't think I can say as much for SVN, though I'm sure it does have a few advantages. And if you're workflow really can't change... SVN certainly works for what it is. It's just not something I'd ever like to go back to.

keerthiko 12y ago

I just wanted to say that even if you don't read this article, this discussion here on HN is very enlightening for people who tend to only use a small subset of git operations in their day-to-day small-team dev tasks (like me).