8 ms·

Bye Bye SVN, Hello Git

56 points by chrisferry 14y ago

rjzzleep 14y ago
i think this is the place to remind of torvalds git talk http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8
compay 14y ago
It's 2012, not 2008. Why is the #2 story right now about a company that switched from SVN to Git?
- recursive 14y ago
  I think there are a lot of people that use subversion.
  - compay 14y ago
    At the risk of sounding like an elitist hipster hacker, the core audience of this site comes here looking to read articles about innovation, not staid, conservative companies slowly transitioning to established and proven technologies.
    - elliottcarlson 14y ago
      A common issue, especially with fast paced startups, is technical debt. This debt can show itself in various ways, and the underlying technology that one uses could be one of those debts. SVN was the popular choice in version control for a long time, and it wouldn't surprise me that there may have been startups that chose this because of comfort-ability in the technology, which has now become a technical debt that will need to be taken care of. Just because you are an elitist hipster hacker, doesn't mean that this issue will only pertain to staid, conservative companies.
    - desade 14y ago
      Even hipster hackers sometimes work for staid, conservative companies. Articles like this one give the hiphacks some ammo when they want to convince management.
    - mlysaght 14y ago
      As I mentioned in an earlier comment, that's the beauty of giving the power to the community to decide what is interesting to them. I wouldn't describe SecondMarket as a staid, conservative company, we use amazing open source technologies such as Solr, Scala, Akka, mongoDB, etc. in a very agile environment. We also like to think we are changing the way in which the financial markets are working. However svn was one technology we were stuck in the past with and we wanted to share that making such a basic change has made our life better.
  - noarchy 14y ago
    Indeed there are. I'm using it right now for a contract job. SVN is just the way things are done there. Before that, they were using TFS.
  - colomon 14y ago
    Sure, and I'm one of them. It's not exactly startling news in 2012 that a lot of people prefer the git/hg model. Hell, I prefer it myself! But I've got a complete svn ecosystem set up here, with 44 projects in a single svn repository, automatic offsite backups, and hundreds of checked-out directories spread across five (or more?) computers with five distinct operating systems. As far as I can see, the one-time costs of moving over completely dwarf the relatively small benefits I would gain from using a better branching model.
    - crosvenir 14y ago
      I'm one of them as well. I'd also love to use git. The issue I have we it is that I feel like the "port" to Windows was more of a crowbar sort of operation rather than a well thought out plan to make a program cross-platform compatible. Install TortoiseSVN. Done. Install TortoiseHg. Oh it needs something else. What's it called? Ok. I need msysGit. I'll get that. Ok, they're all in beta? Whatever I'll just get one. What? It runs on top of Cywin? And on, and on... Am I missing something here or is it really that convoluted? I work with non-programmers (engineering types) who program and I need it to be easy for them. Any recommendations?
      - jurre 14y ago
        The guide at github[0] is pretty easy to follow. I've done it on some of my fellow students' pc's a couple of times during a project, but most of them switched to Ubuntu after a couple of weeks. [0]http://help.github.com/win-set-up-git/ http://help.github.com/win-set-up-git/
        crosvenir 14y ago
        This is a really great setup tutorial that I haven't seen before. Thanks!
      - RobAtticus 14y ago
        I assume you meant TortoiseGit? Otherwise, I think I spot the problem. (Just pointing out because TortoiseHg actually is fairly painless to install if you want to use Mercurial on Windows, and the typo might confuse some)
- astrodust 14y ago
  I was wondering if there was something new in here. Instead it's a tale of a company that's been living under a rock for the last four years.
  - 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.]
- rollypolly 14y ago
  I'd be more interested to hear about companies who switched from Perforce to Git. Perforce seems to be entrenched in more corporate environments.
  - ronnier 14y ago
    We are doing that at Amazon. I made the switch a couple months ago but it's up to each team when they'd like to switch. My team is lucky in that we have a couple people who really know Git well.
  - icefox 14y ago
    Anything in particular you would like to know? I have done it twice. First at Trolltech where Qt was moved over (I want to say there are a handful of public blogs on this) and I have helped with a bunch of perforce/git migration/integration at RIM and consulted with various other companies.
    - rollypolly 14y ago
      Can you describe your largest migration, in terms of users affected and the repository size? Did you experience some of the issues Facebook has? See: http://thread.gmane.org/gmane.comp.version-control.git/189776 http://thread.gmane.org/gmane.comp.version-control.git/18977...
      - icefox 14y ago
        I can't give explicit numbers, but yes I experienced some of the issues Facebook wrote about. This particular problem stems from SVN/Perforce and how they give the user the ability to only checkout part of the repo. Setup 1 exploites this. This would be movie companies were every version of every rendering is in Perforce. On the server you have easily many times even the size of the desktop hd, and users only grab what they need/want. These companies should stick with Perforce. Setup 2 came about from laziness. Everything was dumped into the repo with no organization. Converting it to git will require a XXXGB repo which while manageable windows can't handle well. You encounter say dozens of copies of the binary sprinkled around inside of the source directory (not even revisioned, just copied with the version included in the file name). Need a copy of every Windows NT CD's stored somewhere? Why not in the src directory!?! Once you cleanup/split this the src repo goes down to a usable size. After the above basic cleanup (which honestly can/should have been done in svn/perforce anyway.) the src repo can still be a large size because the src isn't the src for one project, but maybe dozens or hundreds of projects that compile to one binary (or some similar setup such as lots of little binaries that are one product). It is then up to you to decide on how you want to proceed. There are a few different approaches with different pros and cons and situation specific. (And discussing them is really a full blog entry not a random hacker news comment). I'll leave you with my law about repo size: When every developer in a company is committing to the same branch the odds that a commit will break the build increases as more developers are hired. Edit: simplified
- MattBearman 14y ago
  I've only just made the switch. Like most people I was stuck with SVN due to my employer using it, and refusing to update. Now I'm freelance I've had the time to put into learning Git and I'm glad I did, but the point is there are still a lot of people using SVN, some of whom will switch to Git in the future, and posts like this can be very useful to them.
  - icefox 14y ago
    > and refusing to update. How true this is. I spoke with one sysadmin who told me that even if 100% of the developers were using git-svn he would never allow git as the official location to store code on the servers and it must be pushed back to svn. I am not sure how to respond to people like that. Edit: When pressed for more details it was clear that he was happy with his svn server setup and didn't want to change and have to learn something new. This was not a logical discussion, but an emotional one and as he ran the servers he had the final say.
    - gaius 14y ago
      It's possible that he was operating under constraints of which you were unaware. One thing that springs to mind is escrow.
    - nicknyc 14y ago
      "didn't want to change and have to learn something new" Resistance to change might be an authority thing - you could just walk around this troll's bridge and see what happens. Try talking to his boss or higher about source control, casually. If his manager asked him to change to GIT he would do it. He might have dismissed you because he believes you're not in a position of power over him or the work required to switch is mundane.
    - efsavage 14y ago
      Good admins resist change. Great admins can tell you why.
- exit 14y ago
  what you're really complaining about is the voting mechanism around here. apparently there was enough interest to bump it to the front page.
  - lsd5you 14y ago
    Surely what he is really complaining about is the people who voted it up. We cannot blame everything on the system.
    - compay 14y ago
      Yup, that's exactly what I meant. Thank you.
- solutionyogi 14y ago
  It only shows that there are many development shops who have not migrated to a more powerful DVCS (either git or mercurial) and we ought to spread word about how inadequate centralized version control systems are.
  - sophacles 14y ago
    I regularly run into dev shops (with code as the product!) that barely use "old style" VCS properly (e.g. CVS, SVN or TFS), and just refuse to look at git for a litany of reasons, largely boiling down to "our tools are magic, we are afraid of this new magic".
- peacemaker 14y ago
  I just started a new job, at it's the first time in a fairly long career I have had to use git instead of svn. The company I joined only recently switched to git too. Thing is, I understand svn. I get it, and I have used it for years and know, almost instinctively now, what will happen when I use the various commands. Git for me just feels overly confusing. I suppose it's just because I'm used to "the old way" but just take a look online at how many articles that are out there trying to explain how git works. Why are so many needed? It feels like there are many more than there are explaining how svn works. By the way, I can see the benefits of git and I feel I'm getting the hang of it quite well now, but I still like svn :)
  - weaksauce 14y ago
    There are so many articles because there are a lot of people out there that really like git. It's like cutting meat with a spoon and then you are given a knife. Everyone is complaining about how you can cut yourself or how two sides of the knife but only one is sharp is confusing but once you know how to use it it is a game changer with respect to actually cutting meat. There are a lot of people passionate about cutting meat. It's not really that hard to learn btw. There are some esoteric things that can be tricky but the Svn workflow can be learned in a day or two tops.
- deleted 14y ago
  [deleted]
- gutes 14y ago
  because it's 2012.
- mlysaght 14y ago
  That's the beauty of giving the power to the community to decide what is interesting to them. There seems to be a lot of people using older source control solutions and for one reason or another haven't made the move to use a better solution. That's what inspired me to write this post in the first place. We made the move and it improved our lives and I simply wanted people to know about it.
- seclorum 14y ago
  4-year cycle of generations of comp-sci grads re-learning the bleeding edge they were ignoring while they were studying?
leetrout 14y ago
Is there a big performance boost for squashing when rebasing? Is it just housekeeping? I like what Paul Stadig had to say on the topic http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebas...
- nirvdrum 14y ago
  It can make reverting a feature easier if the branch being merged had intermingled with master several times. You could avoid that by rebasing your topic branch before merging, but that's lying too. I personally never rebase unless I need to fix a commit message and I only squash merge if I had a series of ping-pong commits while trying to fix something.
Osiris 14y ago
I just recently switched to Git after joining a new company. The team I'm on was just in the process of switching from SVN to Git, so we were all spending a lot of time online in Pro Git as well as researching various workflows. I think that we're still not fully taking advantage of Git because the other members of the team tend to commit and push all the time (so the code is backed up) but that makes rebasing and squashing quite difficult. Git has also allowed us to work better with maintaining feature branches and bug fix branches which helps us to give individual branches to QA for test and only release those features/fixes that have been QA approved. If a feature isn't ready on time for deployment, it just doesn't get added to the integration branch and it'll go out the next release. That's pretty cool. Personally, I've settled on using SourceTree as a GUI with a fallback to the command-line for certain operations.
- leetrout 14y ago
  Do you have an anecdote about why having more commits have made rebasing / squashing difficult? Is it just that team members are pushing their numerous changes to the central repo? I'm wondering if I'm missing something because I never squash commits...
  - maw 14y ago
    Chances are they're pushing to the same branch or to the same small number of branches instead of to private-ish branches. This is an easy trap to fall into: lots of people have a hard time getting used to using branches for everything. As for squashing or not, I rarely do, and in general only squash commits that are simple typo fixes. This makes bisecting much easier. Also, and this may or may not be relevant, maybe some people are reluctant to spam the central repository with their own temporary branches. To avoid this, I have everyone in my team set up a personal, backed up repository. Anyone can pull from these personal repos, but only their owners can push to them. When the temporary branches are done, they can be merged.
eblume 14y ago
I personally discourage the use of squash, I think that everyone benefits with more granular commits. Is this not common practice?
- mlysaght 14y ago
  We think that a repository with too much noise isn't so useful. When you squash you should use common sense and aggregate the commit comments as you see fit.
ankimal 14y ago
The best practices for git IMHO: https://github.com/nvie/gitflow https://github.com/nvie/gitflow
- thibaut_barrere 14y ago
  We used that a bit but in the end it it was overkill for our needs. All our projects are now handled in "githubflow" mode.
georgieporgie 14y ago
Historically with SVN, branching was skittish. Really? How? I've always found Subversion branching to be painless, reliable, fast enough, and merges often go flawlessly, and it's really not been that hard to resolve merge conflicts.
- cheald 14y ago
  Branching with SVN requires creating a separate copy of the entire repository, effectively. It rapidly becomes unwieldy with larger projects.

56 points by chrisferry 14y ago

i think this is the place to remind of torvalds git talk http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8

compay 14y ago

It's 2012, not 2008. Why is the #2 story right now about a company that switched from SVN to Git?

recursive 14y ago
I think there are a lot of people that use subversion.
- compay 14y ago
  At the risk of sounding like an elitist hipster hacker, the core audience of this site comes here looking to read articles about innovation, not staid, conservative companies slowly transitioning to established and proven technologies.
  - elliottcarlson 14y ago
    A common issue, especially with fast paced startups, is technical debt. This debt can show itself in various ways, and the underlying technology that one uses could be one of those debts. SVN was the popular choice in version control for a long time, and it wouldn't surprise me that there may have been startups that chose this because of comfort-ability in the technology, which has now become a technical debt that will need to be taken care of. Just because you are an elitist hipster hacker, doesn't mean that this issue will only pertain to staid, conservative companies.
  - desade 14y ago
    Even hipster hackers sometimes work for staid, conservative companies. Articles like this one give the hiphacks some ammo when they want to convince management.
  - mlysaght 14y ago
    As I mentioned in an earlier comment, that's the beauty of giving the power to the community to decide what is interesting to them. I wouldn't describe SecondMarket as a staid, conservative company, we use amazing open source technologies such as Solr, Scala, Akka, mongoDB, etc. in a very agile environment. We also like to think we are changing the way in which the financial markets are working. However svn was one technology we were stuck in the past with and we wanted to share that making such a basic change has made our life better.
- noarchy 14y ago
  Indeed there are. I'm using it right now for a contract job. SVN is just the way things are done there. Before that, they were using TFS.
- colomon 14y ago
  Sure, and I'm one of them. It's not exactly startling news in 2012 that a lot of people prefer the git/hg model. Hell, I prefer it myself! But I've got a complete svn ecosystem set up here, with 44 projects in a single svn repository, automatic offsite backups, and hundreds of checked-out directories spread across five (or more?) computers with five distinct operating systems. As far as I can see, the one-time costs of moving over completely dwarf the relatively small benefits I would gain from using a better branching model.
  - crosvenir 14y ago
    I'm one of them as well. I'd also love to use git. The issue I have we it is that I feel like the "port" to Windows was more of a crowbar sort of operation rather than a well thought out plan to make a program cross-platform compatible. Install TortoiseSVN. Done. Install TortoiseHg. Oh it needs something else. What's it called? Ok. I need msysGit. I'll get that. Ok, they're all in beta? Whatever I'll just get one. What? It runs on top of Cywin? And on, and on... Am I missing something here or is it really that convoluted? I work with non-programmers (engineering types) who program and I need it to be easy for them. Any recommendations?
    - jurre 14y ago
      The guide at github[0] is pretty easy to follow. I've done it on some of my fellow students' pc's a couple of times during a project, but most of them switched to Ubuntu after a couple of weeks. [0]http://help.github.com/win-set-up-git/ http://help.github.com/win-set-up-git/
      - crosvenir 14y ago
        This is a really great setup tutorial that I haven't seen before. Thanks!
    - RobAtticus 14y ago
      I assume you meant TortoiseGit? Otherwise, I think I spot the problem. (Just pointing out because TortoiseHg actually is fairly painless to install if you want to use Mercurial on Windows, and the typo might confuse some)
astrodust 14y ago
I was wondering if there was something new in here. Instead it's a tale of a company that's been living under a rock for the last four years.
- 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.]
rollypolly 14y ago
I'd be more interested to hear about companies who switched from Perforce to Git. Perforce seems to be entrenched in more corporate environments.
- ronnier 14y ago
  We are doing that at Amazon. I made the switch a couple months ago but it's up to each team when they'd like to switch. My team is lucky in that we have a couple people who really know Git well.
- icefox 14y ago
  Anything in particular you would like to know? I have done it twice. First at Trolltech where Qt was moved over (I want to say there are a handful of public blogs on this) and I have helped with a bunch of perforce/git migration/integration at RIM and consulted with various other companies.
  - rollypolly 14y ago
    Can you describe your largest migration, in terms of users affected and the repository size? Did you experience some of the issues Facebook has? See: http://thread.gmane.org/gmane.comp.version-control.git/189776 http://thread.gmane.org/gmane.comp.version-control.git/18977...
    - icefox 14y ago
      I can't give explicit numbers, but yes I experienced some of the issues Facebook wrote about. This particular problem stems from SVN/Perforce and how they give the user the ability to only checkout part of the repo. Setup 1 exploites this. This would be movie companies were every version of every rendering is in Perforce. On the server you have easily many times even the size of the desktop hd, and users only grab what they need/want. These companies should stick with Perforce. Setup 2 came about from laziness. Everything was dumped into the repo with no organization. Converting it to git will require a XXXGB repo which while manageable windows can't handle well. You encounter say dozens of copies of the binary sprinkled around inside of the source directory (not even revisioned, just copied with the version included in the file name). Need a copy of every Windows NT CD's stored somewhere? Why not in the src directory!?! Once you cleanup/split this the src repo goes down to a usable size. After the above basic cleanup (which honestly can/should have been done in svn/perforce anyway.) the src repo can still be a large size because the src isn't the src for one project, but maybe dozens or hundreds of projects that compile to one binary (or some similar setup such as lots of little binaries that are one product). It is then up to you to decide on how you want to proceed. There are a few different approaches with different pros and cons and situation specific. (And discussing them is really a full blog entry not a random hacker news comment). I'll leave you with my law about repo size: When every developer in a company is committing to the same branch the odds that a commit will break the build increases as more developers are hired. Edit: simplified
MattBearman 14y ago
I've only just made the switch. Like most people I was stuck with SVN due to my employer using it, and refusing to update. Now I'm freelance I've had the time to put into learning Git and I'm glad I did, but the point is there are still a lot of people using SVN, some of whom will switch to Git in the future, and posts like this can be very useful to them.
- icefox 14y ago
  > and refusing to update. How true this is. I spoke with one sysadmin who told me that even if 100% of the developers were using git-svn he would never allow git as the official location to store code on the servers and it must be pushed back to svn. I am not sure how to respond to people like that. Edit: When pressed for more details it was clear that he was happy with his svn server setup and didn't want to change and have to learn something new. This was not a logical discussion, but an emotional one and as he ran the servers he had the final say.
  - gaius 14y ago
    It's possible that he was operating under constraints of which you were unaware. One thing that springs to mind is escrow.
  - nicknyc 14y ago
    "didn't want to change and have to learn something new" Resistance to change might be an authority thing - you could just walk around this troll's bridge and see what happens. Try talking to his boss or higher about source control, casually. If his manager asked him to change to GIT he would do it. He might have dismissed you because he believes you're not in a position of power over him or the work required to switch is mundane.
  - efsavage 14y ago
    Good admins resist change. Great admins can tell you why.
exit 14y ago
what you're really complaining about is the voting mechanism around here. apparently there was enough interest to bump it to the front page.
- lsd5you 14y ago
  Surely what he is really complaining about is the people who voted it up. We cannot blame everything on the system.
  - compay 14y ago
    Yup, that's exactly what I meant. Thank you.
solutionyogi 14y ago
It only shows that there are many development shops who have not migrated to a more powerful DVCS (either git or mercurial) and we ought to spread word about how inadequate centralized version control systems are.
- sophacles 14y ago
  I regularly run into dev shops (with code as the product!) that barely use "old style" VCS properly (e.g. CVS, SVN or TFS), and just refuse to look at git for a litany of reasons, largely boiling down to "our tools are magic, we are afraid of this new magic".
peacemaker 14y ago
I just started a new job, at it's the first time in a fairly long career I have had to use git instead of svn. The company I joined only recently switched to git too. Thing is, I understand svn. I get it, and I have used it for years and know, almost instinctively now, what will happen when I use the various commands. Git for me just feels overly confusing. I suppose it's just because I'm used to "the old way" but just take a look online at how many articles that are out there trying to explain how git works. Why are so many needed? It feels like there are many more than there are explaining how svn works. By the way, I can see the benefits of git and I feel I'm getting the hang of it quite well now, but I still like svn :)
- weaksauce 14y ago
  There are so many articles because there are a lot of people out there that really like git. It's like cutting meat with a spoon and then you are given a knife. Everyone is complaining about how you can cut yourself or how two sides of the knife but only one is sharp is confusing but once you know how to use it it is a game changer with respect to actually cutting meat. There are a lot of people passionate about cutting meat. It's not really that hard to learn btw. There are some esoteric things that can be tricky but the Svn workflow can be learned in a day or two tops.
deleted 14y ago
[deleted]
gutes 14y ago
because it's 2012.
mlysaght 14y ago
That's the beauty of giving the power to the community to decide what is interesting to them. There seems to be a lot of people using older source control solutions and for one reason or another haven't made the move to use a better solution. That's what inspired me to write this post in the first place. We made the move and it improved our lives and I simply wanted people to know about it.
seclorum 14y ago
4-year cycle of generations of comp-sci grads re-learning the bleeding edge they were ignoring while they were studying?

leetrout 14y ago

Is there a big performance boost for squashing when rebasing? Is it just housekeeping? I like what Paul Stadig had to say on the topic http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebas...

nirvdrum 14y ago
It can make reverting a feature easier if the branch being merged had intermingled with master several times. You could avoid that by rebasing your topic branch before merging, but that's lying too. I personally never rebase unless I need to fix a commit message and I only squash merge if I had a series of ping-pong commits while trying to fix something.

Osiris 14y ago

I just recently switched to Git after joining a new company. The team I'm on was just in the process of switching from SVN to Git, so we were all spending a lot of time online in Pro Git as well as researching various workflows. I think that we're still not fully taking advantage of Git because the other members of the team tend to commit and push all the time (so the code is backed up) but that makes rebasing and squashing quite difficult. Git has also allowed us to work better with maintaining feature branches and bug fix branches which helps us to give individual branches to QA for test and only release those features/fixes that have been QA approved. If a feature isn't ready on time for deployment, it just doesn't get added to the integration branch and it'll go out the next release. That's pretty cool. Personally, I've settled on using SourceTree as a GUI with a fallback to the command-line for certain operations.

leetrout 14y ago
Do you have an anecdote about why having more commits have made rebasing / squashing difficult? Is it just that team members are pushing their numerous changes to the central repo? I'm wondering if I'm missing something because I never squash commits...
- maw 14y ago
  Chances are they're pushing to the same branch or to the same small number of branches instead of to private-ish branches. This is an easy trap to fall into: lots of people have a hard time getting used to using branches for everything. As for squashing or not, I rarely do, and in general only squash commits that are simple typo fixes. This makes bisecting much easier. Also, and this may or may not be relevant, maybe some people are reluctant to spam the central repository with their own temporary branches. To avoid this, I have everyone in my team set up a personal, backed up repository. Anyone can pull from these personal repos, but only their owners can push to them. When the temporary branches are done, they can be merged.

eblume 14y ago

I personally discourage the use of squash, I think that everyone benefits with more granular commits. Is this not common practice?

mlysaght 14y ago
We think that a repository with too much noise isn't so useful. When you squash you should use common sense and aggregate the commit comments as you see fit.

ankimal 14y ago

The best practices for git IMHO: https://github.com/nvie/gitflow https://github.com/nvie/gitflow

thibaut_barrere 14y ago
We used that a bit but in the end it it was overkill for our needs. All our projects are now handled in "githubflow" mode.

georgieporgie 14y ago

Historically with SVN, branching was skittish. Really? How? I've always found Subversion branching to be painless, reliable, fast enough, and merges often go flawlessly, and it's really not been that hard to resolve merge conflicts.

cheald 14y ago
Branching with SVN requires creating a separate copy of the entire repository, effectively. It rapidly becomes unwieldy with larger projects.