7 ms·

Under a rock? Is git _that_ much better? I used to read about how it didn't need a central repository, yet this article, and github, seem to indicate everyone

by dneb7 14y ago

Under a rock? Is git _that_ much better? I used to read about how it didn't need a central repository, yet this article, and github, seem to indicate everyone ultimately wants/needs a central repository. So git is worth switching just for branching/merging superiority? Maybe I don't do it enough, but svn has never let me down. Or maybe I'm not on a large enough dev team? Guess I'm really just trying to figure out if git is so amazingly better that I really am under a rock (I'm not seeing that), or if it's more of the "if you're not using {latest hip tech} you're not to be taken seriously" kind of thing that we see so much on HN. (sorry about new account -- can't find original credentials)

rimantas 14y ago
Yes, git is that much better. Branching is only part of that. Another part is speed—and especially network speed. Git makes operations, during which in SVN I could go, make some coffee and come back just to find them still running, instananeous. Then there is rebasing. Then there is differntiation between author and commiter. Etc., etc.
solutionyogi 14y ago
Yes, git is THAT MUCH BETTER. I wish I had time to get in all the details about why git is better but I will leave you with two questions to ask your existing version control system: 1. How fast is your version control system? Unless you have tried git, you will not realize how painfully slow SVN (or any other VCS which has to talk to server) is. 90% of my git operations take less than a second. Now, you may say that 'speed' is not an issue. Trust me, it is. Once you have a super fast VCS, you will embrace it as your friend in everyday coding instead of using it at the end of the day. It's something similar to what Google thinks that making website/webapp faster brings in more users. 2. Can your version control handle renames? There are very few version control systems out there which can handle renames. If you dread renaming files because of SVN, you ought to look at git. BTW, not only can git handle renames without a hitch, it can show you code history across file renames. Again, you may think that 'renaming' is not an issue. But if you believe that 'naming' is very important for your code and you do re-factoring all the time, you don't want your version control system to dictate how you work. I can imagine why one may think that git is fad. But after using it for 2 years now, I can not use any other version control system. [And for a background, I have used following version control systems for real proejcts: CVS, VSS, Perforce, Surround SCM, SVN, TFS.]
- luser001 14y ago
  Yes, SVN can handle renames. And maintain history across renames. Btw, SVN supports partial checkouts (git doesn't). Which I use regularly on a gigabyte repo. I use git regularly for all my hobby projects (mainly because 'git init' seems way simpler than the equivalent svn command), and I might even start a company off on git, but I'll never claim that SVN is obviously a bad way to do things.
  - prolepunk 14y ago
    Git supports grafting, also using enormous multigigabyte svn repository that contain numerous projects is SVN cancer.
- montecarl 14y ago
  Do you care to elaborate on point #2? In svn I can do "svn mv" to rename files. I don't see how this is more difficult than just "mv". Maybe the history of file renames is somehow more easy to follow in git? If I run "svn log renamedfile", I can see the history across file changes.
  - solutionyogi 14y ago
    With git, I don't have to tell it that I renamed file. It can even figure out if I moved the file from one folder to another. And with git, I can see the complete history without worrying about the fact that the name might have changed in the past.
- figglesonrails 14y ago
  I use SVN at home and in a 9-5. It's works fine. 1) Fast enough? I have tried git. It's pretty cool, but the difference between 5 seconds and 1 second is minimal at best to me. I don't think I've found myself dying for a faster SCM, though I usually make maybe 1 - 5 commits per day. Git on Win32 is meh compared to git on Linux, so that doesn't really convince me any further either. Git is also a PITA to compile on !Linux using !gcc, because heaven forbid we write using ANSI/ISO C. 2) Yes? I can do renames, but strictly speaking it is not an atomic "rename" operation. I don't particularly care about rename history, and I'm not really sure why others do, but I guess if I tried I could make up a use-case for it. Still, it wouldn't be a selling feature for me, that's for sure. It seems strange to me that you take the time to tell us that "git is better", like we're comparing O(n) to O(log(n)) algorithms. Different workflows, projects, and organization structures have different needs. It seems hopelessly naive to simply assume everyone's needs are best fit by git, and git alone. How about this: I want to tell, given two revision numbers in the mainline branch, which came first? In SVN, it's pretty simple. In git? Well, first open a terminal...then ...argh. As release manager, it's kind of annoying. Simple use case: is 2aa8aca05357004d4418807c06f53d81517bc629 before or after e8d0555ce401b6acb0f225aa0263e9b72136347d? Did e8d0555ce401b6acb0f225aa0263e9b72136347d make it into the build given that 5b5c73ceaa442bafff08b4470aad3ff276be94e3 was the final commit before the cut-off? I might waste 5 seconds opening a terminal window or tab, 30 seconds finding, copying, and pasting the revision numbers, then a second or two determining the answer. This, to me, is not a productive use of my time when revision numbers simply tell me what I need to know. All of that magical time git just saved me might have just been absorbed or gone into time debt.
compay 14y ago
> github, seem to indicate everyone ultimately wants/needs a central repository Of course you still need some centralization in order to share work with other people. But the more compelling thing about Github is forking, not centralization. With Git you can easily synchronize commits between multiple remote repositories.
aSig 14y ago
There's a fair few extra features you wouldn't think you would need but you'll discover mainly through using it. We made the switch from svn to git a while back and I can't imagine how we used to get by without stash, cherry-pick, bisect etc. There's more to git than just a distributed repository and better branching for sure.
MBlume 14y ago
Simple difference: in svn, until you're ready for other people to see your changes, you have to leave them uncommitted. In git, you say "well, I just refactored function X, let's throw that in a commit before I do anything else, and if I have to revisit it, I will" I've never had to use svn myself, but it's this aspect that's always sounded positively crippling to my workflow
- adestefan 14y ago
  This is about the only gripe I have about svn. Otherwise, we're so deep into the svn ecosystem that it would be a monumental shift.
justsomedood 14y ago
Even at that, branching isn't hard at all on Subversion. I know that before 1.6 it was more cumbersome, but making a branch for my work and committing a lot of small changes and then merging back when done isn't hard. There's also the benefit of being able to checkout just one folder of the project wherever you want without having to keep the same folder structure as the source project. I understand git is able to do a "sparse" checkout now, but the parent source folder structure is checked as well.
nirvdrum 14y ago
I agree. The entire Internet would have you believe that OSS just didn't exist before the advent of git. I like git and prefer it, but SVN gets the job done. My only real gripe with SVN is it makes it harder for those without commit privileges to commit. Within a company setting, that point is moot. A lot of the other anti-SVN sentiment is based around old versions of SVN. It still doesn't branch as fast as git, but it does have merge tracking. At the end of the day, use what works best for you. If you want to test the waters, use git-svn. You can then work locally and then dcommit your changes when they're ready to go upstream. It'll give you a pretty good approximation of what git can do for you workflow-wise.

by dneb7 14y ago

rimantas 14y ago

Yes, git is that much better. Branching is only part of that. Another part is speed—and especially network speed. Git makes operations, during which in SVN I could go, make some coffee and come back just to find them still running, instananeous. Then there is rebasing. Then there is differntiation between author and commiter. Etc., etc.

solutionyogi 14y ago

Yes, git is THAT MUCH BETTER. I wish I had time to get in all the details about why git is better but I will leave you with two questions to ask your existing version control system: 1. How fast is your version control system? Unless you have tried git, you will not realize how painfully slow SVN (or any other VCS which has to talk to server) is. 90% of my git operations take less than a second. Now, you may say that 'speed' is not an issue. Trust me, it is. Once you have a super fast VCS, you will embrace it as your friend in everyday coding instead of using it at the end of the day. It's something similar to what Google thinks that making website/webapp faster brings in more users. 2. Can your version control handle renames? There are very few version control systems out there which can handle renames. If you dread renaming files because of SVN, you ought to look at git. BTW, not only can git handle renames without a hitch, it can show you code history across file renames. Again, you may think that 'renaming' is not an issue. But if you believe that 'naming' is very important for your code and you do re-factoring all the time, you don't want your version control system to dictate how you work. I can imagine why one may think that git is fad. But after using it for 2 years now, I can not use any other version control system. [And for a background, I have used following version control systems for real proejcts: CVS, VSS, Perforce, Surround SCM, SVN, TFS.]

luser001 14y ago
Yes, SVN can handle renames. And maintain history across renames. Btw, SVN supports partial checkouts (git doesn't). Which I use regularly on a gigabyte repo. I use git regularly for all my hobby projects (mainly because 'git init' seems way simpler than the equivalent svn command), and I might even start a company off on git, but I'll never claim that SVN is obviously a bad way to do things.
- prolepunk 14y ago
  Git supports grafting, also using enormous multigigabyte svn repository that contain numerous projects is SVN cancer.
montecarl 14y ago
Do you care to elaborate on point #2? In svn I can do "svn mv" to rename files. I don't see how this is more difficult than just "mv". Maybe the history of file renames is somehow more easy to follow in git? If I run "svn log renamedfile", I can see the history across file changes.
- solutionyogi 14y ago
  With git, I don't have to tell it that I renamed file. It can even figure out if I moved the file from one folder to another. And with git, I can see the complete history without worrying about the fact that the name might have changed in the past.
figglesonrails 14y ago
I use SVN at home and in a 9-5. It's works fine. 1) Fast enough? I have tried git. It's pretty cool, but the difference between 5 seconds and 1 second is minimal at best to me. I don't think I've found myself dying for a faster SCM, though I usually make maybe 1 - 5 commits per day. Git on Win32 is meh compared to git on Linux, so that doesn't really convince me any further either. Git is also a PITA to compile on !Linux using !gcc, because heaven forbid we write using ANSI/ISO C. 2) Yes? I can do renames, but strictly speaking it is not an atomic "rename" operation. I don't particularly care about rename history, and I'm not really sure why others do, but I guess if I tried I could make up a use-case for it. Still, it wouldn't be a selling feature for me, that's for sure. It seems strange to me that you take the time to tell us that "git is better", like we're comparing O(n) to O(log(n)) algorithms. Different workflows, projects, and organization structures have different needs. It seems hopelessly naive to simply assume everyone's needs are best fit by git, and git alone. How about this: I want to tell, given two revision numbers in the mainline branch, which came first? In SVN, it's pretty simple. In git? Well, first open a terminal...then ...argh. As release manager, it's kind of annoying. Simple use case: is 2aa8aca05357004d4418807c06f53d81517bc629 before or after e8d0555ce401b6acb0f225aa0263e9b72136347d? Did e8d0555ce401b6acb0f225aa0263e9b72136347d make it into the build given that 5b5c73ceaa442bafff08b4470aad3ff276be94e3 was the final commit before the cut-off? I might waste 5 seconds opening a terminal window or tab, 30 seconds finding, copying, and pasting the revision numbers, then a second or two determining the answer. This, to me, is not a productive use of my time when revision numbers simply tell me what I need to know. All of that magical time git just saved me might have just been absorbed or gone into time debt.

compay 14y ago

> github, seem to indicate everyone ultimately wants/needs a central repository Of course you still need some centralization in order to share work with other people. But the more compelling thing about Github is forking, not centralization. With Git you can easily synchronize commits between multiple remote repositories.

aSig 14y ago

There's a fair few extra features you wouldn't think you would need but you'll discover mainly through using it. We made the switch from svn to git a while back and I can't imagine how we used to get by without stash, cherry-pick, bisect etc. There's more to git than just a distributed repository and better branching for sure.

MBlume 14y ago

Simple difference: in svn, until you're ready for other people to see your changes, you have to leave them uncommitted. In git, you say "well, I just refactored function X, let's throw that in a commit before I do anything else, and if I have to revisit it, I will" I've never had to use svn myself, but it's this aspect that's always sounded positively crippling to my workflow

adestefan 14y ago
This is about the only gripe I have about svn. Otherwise, we're so deep into the svn ecosystem that it would be a monumental shift.

justsomedood 14y ago

Even at that, branching isn't hard at all on Subversion. I know that before 1.6 it was more cumbersome, but making a branch for my work and committing a lot of small changes and then merging back when done isn't hard. There's also the benefit of being able to checkout just one folder of the project wherever you want without having to keep the same folder structure as the source project. I understand git is able to do a "sparse" checkout now, but the parent source folder structure is checked as well.

nirvdrum 14y ago

I agree. The entire Internet would have you believe that OSS just didn't exist before the advent of git. I like git and prefer it, but SVN gets the job done. My only real gripe with SVN is it makes it harder for those without commit privileges to commit. Within a company setting, that point is moot. A lot of the other anti-SVN sentiment is based around old versions of SVN. It still doesn't branch as fast as git, but it does have merge tracking. At the end of the day, use what works best for you. If you want to test the waters, use git-svn. You can then work locally and then dcommit your changes when they're ready to go upstream. It'll give you a pretty good approximation of what git can do for you workflow-wise.