3 ms·

Say what you want about Git, GitHub is awesome.

by lanna 14y ago

benatkin 14y ago
Say what you want about GitHub, Git is awesome. (Not sure why we're comparing them but I'll throw in my opposing opinion. I actually like both but Git itself is much more important to me than GitHub.)
- m_mueller 14y ago
  Honest question: If it's not for GitHub's community features that get enabled through git's decentralized repository, what does git do for you more than a local SVN server?
  - zachlatta 14y ago
    For one, decentralized version control.
  - trustfundbaby 14y ago
    the spectacular ease of creating and merging branches is a huge one.
  - Schwolop 14y ago
    I used to use SVN. We built control software for robots. We'd take the robots away on a field trial - no internet access - fix some bugs, write some code, add some features. That's five to ten people, all writing code that interacts with each other's, all without any access to the SVN server. You can imagine the copy-pasta that went on. The amount of "oh fuck, I just rebuilt-all without Dave's changes". The amount of "Bags not merging this shit." Then we'd get back to work after a weekend and have to merge all our independent branches. That could take a day or two on its own. Sometimes, sitting with five people's laptops in front of you and using the human brain's visual diff was more efficient than trying to do it properly. --- Now, with git, we push and pull wherever the hell we like as needed. Everyone's laptop is equivalent to the server. When we get back, everyone merges their stuff into staging, all the cross-dependencies get magically resolved, we test it, and merge that into master. It takes about fifteen minutes. (Actually, I don't work there any more, but the conclusion works better in the present tense.)
    - m_mueller 14y ago
      Thanks, that's an interesting example. Yes, I can absolutely see that for truly collaborative projects where multiple programming tasks over the same code portions run in parallel, git becomes a real time saver. I just haven't run into such a project yet myself.
  - jlarocco 14y ago
    The fact that Git can be used without a server is a big benefit. Being able to do "git init" in any directory and start versioning files is pretty nice. And Git handles branching and merging better than Subversion.
  - jmathai 14y ago
    Honest response: If you're coming from a Subversion background (like I did) then wrapping your head around the possibilities of git takes a long time. You almost have to unlearn everything you knew about version control. If you're not frequently using local branches, your stash, `git add --patch`, git bisect or git rebase then you're really missing out. Everyone's git workflow is different which makes it even harder to get up to speed since you read about 10 ways to accomplish the same task. You might not use ALL the features of git but once you master a subset of them you'll find that your workflow is unlike anything you could have done with Subversion.
    - marssaxman 14y ago
      Wrapping your head around git takes a long time regardless of your background, because git's interface is incoherent and requires you to understand internal details of its implementation to a degree I haven't seen in a commonly used dev tool since the '80s.
      - jlgreco 14y ago
        I don't think this is really true. Sure, you have to learn the (absurdly simple) model that git uses behind the scenes, but after you do that, who really cares about the standard CLI interface? That interface sucks in the same way a dashboard might suck on an all-terrian vehicle. Sure it looks like shit, all the knobs are in the wrong place and don't turn in consistent ways, and that analog clock seems really out of place in a car... but who really cares? It doesn't impede actual use. Those "internal details of its implementation" are in fact what git actually is. "Learning git" without learning that stuff is not in fact learning git.
        marssaxman 14y ago
        I agree with you, basically, but that is the substance of my complaint. Git leaves all of its messy internal bits exposed and does not provide a clean abstraction layer in its interface. Many people have written such abstraction layers, but they tend to be incomplete, and none of them is a standard. Everyone who wants to use git - which includes everyone who wants to merely collaborate with other people who use git - therefore has to learn git's internal implementation details. It's one thing to learn the internal implementation details when you are a power user who really cares about a particular tool and wants to master it: it's another thing to require everyone to gain low-level familiarity. The whole point of a computer - indeed, the whole point of computing, if you look at it through a lambda-calculus lens - is to provide abstractions over lower-level details, thereby allowing human brains to spend less time worrying about those details and more time manipulating higher-level abstract concepts. In failing to offer a high-level interface, git wastes human brainpower which could otherwise be spent solving actual problems. You don't need to know what an AST or a symbol table or an intermediate representation are to use gcc; you don't need to understand static single-assignment form, linker relocation entries, or ELF segments. You can use the tool without any knowledge of its internal mechanisms. This is not true of Git, and that is why I hope it can be improved or replaced with something that has more respect for human brain power.
  - jacquesm 14y ago
    > what does git do for you more than a local SVN server? It does less than a local SVN server, there is no server. Git is peer-to-peer, which is a huge advantage. Because it is decentralized you can access your whole repo and its history while off-line. That and easy branching are the main selling points of Git though over time you discover more and more ways in which Git is subtly superior. If I could start over again on my main repo I'd do it in Git but I already have all my files dating back a long time in an svn repository so the cost of transiting is huge. (it is a very large repository). But anything new is stored in Git. Maybe one day I'll work up the courage to do a proper transition.
    - sergiosgc 14y ago
      git-svn does it perfectly. We use it to track OSS projects that use SVN (we use git internally). So far, it has proven to be very reliable.
  - ksherlock 14y ago
    I prefer git because it stays out of your way. No more .svn garbage littering every folder. No more "mother may I?" before deleting or moving files. And no more URLs when branching and merging.
beefsack 14y ago
I haven't heard too many people say bad things about Git.
- m_mueller 14y ago
  Git's technology is awesome, but are you happy with its CLI?
- ianstormtaylor 14y ago
  The CLI for Git could use a lot of design help.
- InclinedPlane 14y ago
  Git is like linux in... 1996 maybe. The underlying technology is pretty awesome, but it leaves a lot to be desired in terms of usability. Git is enormously powerful, but it has some key weak spots that can lead to intense frustration, and it doesn't exactly guide users into using it in the best way possible.
  - mserdarsanli 14y ago
    I'm to young to know about linux in 1996, but linux in 2013 also seems to fit what you describe.
    - InclinedPlane 14y ago
      Imagine linux back in an age before it was possible to search the web for answers to problems you run into. In an age when some of the most popular linux distros not only didn't have advanced install-on-demand internet based package management (e.g. debian) but may not have had any package management at all. Also in an age when plug-and-play was still more a theory than a reality and when hardware support in linux was a cruel joke. Add to that a dizzying array of competing distros and hardware so slow it usually took hours to do a kernel compile. It was a frustrating time for computing in general and deciding to try using linux was a fairly daring venture certain to result in hours upon hours of frustration.

Say what you want about Git, GitHub is awesome.

by lanna 14y ago

Say what you want about Git, GitHub is awesome.

Say what you want about GitHub, Git is awesome. (Not sure why we're comparing them but I'll throw in my opposing opinion. I actually like both but Git itself is much more important to me than GitHub.)

m_mueller 14y ago
Honest question: If it's not for GitHub's community features that get enabled through git's decentralized repository, what does git do for you more than a local SVN server?
- zachlatta 14y ago
  For one, decentralized version control.
- trustfundbaby 14y ago
  the spectacular ease of creating and merging branches is a huge one.
- Schwolop 14y ago
  I used to use SVN. We built control software for robots. We'd take the robots away on a field trial - no internet access - fix some bugs, write some code, add some features. That's five to ten people, all writing code that interacts with each other's, all without any access to the SVN server. You can imagine the copy-pasta that went on. The amount of "oh fuck, I just rebuilt-all without Dave's changes". The amount of "Bags not merging this shit." Then we'd get back to work after a weekend and have to merge all our independent branches. That could take a day or two on its own. Sometimes, sitting with five people's laptops in front of you and using the human brain's visual diff was more efficient than trying to do it properly. --- Now, with git, we push and pull wherever the hell we like as needed. Everyone's laptop is equivalent to the server. When we get back, everyone merges their stuff into staging, all the cross-dependencies get magically resolved, we test it, and merge that into master. It takes about fifteen minutes. (Actually, I don't work there any more, but the conclusion works better in the present tense.)
  - m_mueller 14y ago
    Thanks, that's an interesting example. Yes, I can absolutely see that for truly collaborative projects where multiple programming tasks over the same code portions run in parallel, git becomes a real time saver. I just haven't run into such a project yet myself.
- jlarocco 14y ago
  The fact that Git can be used without a server is a big benefit. Being able to do "git init" in any directory and start versioning files is pretty nice. And Git handles branching and merging better than Subversion.
- jmathai 14y ago
  Honest response: If you're coming from a Subversion background (like I did) then wrapping your head around the possibilities of git takes a long time. You almost have to unlearn everything you knew about version control. If you're not frequently using local branches, your stash, `git add --patch`, git bisect or git rebase then you're really missing out. Everyone's git workflow is different which makes it even harder to get up to speed since you read about 10 ways to accomplish the same task. You might not use ALL the features of git but once you master a subset of them you'll find that your workflow is unlike anything you could have done with Subversion.
  - marssaxman 14y ago
    Wrapping your head around git takes a long time regardless of your background, because git's interface is incoherent and requires you to understand internal details of its implementation to a degree I haven't seen in a commonly used dev tool since the '80s.
    - jlgreco 14y ago
      I don't think this is really true. Sure, you have to learn the (absurdly simple) model that git uses behind the scenes, but after you do that, who really cares about the standard CLI interface? That interface sucks in the same way a dashboard might suck on an all-terrian vehicle. Sure it looks like shit, all the knobs are in the wrong place and don't turn in consistent ways, and that analog clock seems really out of place in a car... but who really cares? It doesn't impede actual use. Those "internal details of its implementation" are in fact what git actually is. "Learning git" without learning that stuff is not in fact learning git.
      - marssaxman 14y ago
        I agree with you, basically, but that is the substance of my complaint. Git leaves all of its messy internal bits exposed and does not provide a clean abstraction layer in its interface. Many people have written such abstraction layers, but they tend to be incomplete, and none of them is a standard. Everyone who wants to use git - which includes everyone who wants to merely collaborate with other people who use git - therefore has to learn git's internal implementation details. It's one thing to learn the internal implementation details when you are a power user who really cares about a particular tool and wants to master it: it's another thing to require everyone to gain low-level familiarity. The whole point of a computer - indeed, the whole point of computing, if you look at it through a lambda-calculus lens - is to provide abstractions over lower-level details, thereby allowing human brains to spend less time worrying about those details and more time manipulating higher-level abstract concepts. In failing to offer a high-level interface, git wastes human brainpower which could otherwise be spent solving actual problems. You don't need to know what an AST or a symbol table or an intermediate representation are to use gcc; you don't need to understand static single-assignment form, linker relocation entries, or ELF segments. You can use the tool without any knowledge of its internal mechanisms. This is not true of Git, and that is why I hope it can be improved or replaced with something that has more respect for human brain power.
- jacquesm 14y ago
  > what does git do for you more than a local SVN server? It does less than a local SVN server, there is no server. Git is peer-to-peer, which is a huge advantage. Because it is decentralized you can access your whole repo and its history while off-line. That and easy branching are the main selling points of Git though over time you discover more and more ways in which Git is subtly superior. If I could start over again on my main repo I'd do it in Git but I already have all my files dating back a long time in an svn repository so the cost of transiting is huge. (it is a very large repository). But anything new is stored in Git. Maybe one day I'll work up the courage to do a proper transition.
  - sergiosgc 14y ago
    git-svn does it perfectly. We use it to track OSS projects that use SVN (we use git internally). So far, it has proven to be very reliable.
- ksherlock 14y ago
  I prefer git because it stays out of your way. No more .svn garbage littering every folder. No more "mother may I?" before deleting or moving files. And no more URLs when branching and merging.

beefsack 14y ago

I haven't heard too many people say bad things about Git.

m_mueller 14y ago
Git's technology is awesome, but are you happy with its CLI?
ianstormtaylor 14y ago
The CLI for Git could use a lot of design help.
InclinedPlane 14y ago
Git is like linux in... 1996 maybe. The underlying technology is pretty awesome, but it leaves a lot to be desired in terms of usability. Git is enormously powerful, but it has some key weak spots that can lead to intense frustration, and it doesn't exactly guide users into using it in the best way possible.
- mserdarsanli 14y ago
  I'm to young to know about linux in 1996, but linux in 2013 also seems to fit what you describe.
  - InclinedPlane 14y ago
    Imagine linux back in an age before it was possible to search the web for answers to problems you run into. In an age when some of the most popular linux distros not only didn't have advanced install-on-demand internet based package management (e.g. debian) but may not have had any package management at all. Also in an age when plug-and-play was still more a theory than a reality and when hardware support in linux was a cruel joke. Add to that a dizzying array of competing distros and hardware so slow it usually took hours to do a kernel compile. It was a frustrating time for computing in general and deciding to try using linux was a fairly daring venture certain to result in hours upon hours of frustration.