Comments on: All That Git Talk in The Rails World, What Gives? http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/ Ruby, Ruby on Rails, Los Angeles, Technology, Geek, Science, Life Thu, 04 Dec 2008 22:34:39 +0000 http://wordpress.org/?v=2.5.1 By: Rajesh Dugga... http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-21016 Rajesh Dugga... Tue, 11 Mar 2008 19:00:18 +0000 http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-21016 e.g. Let's say you've got 5 developer's. With a distributed repo.. each developer can create as many branches as they want in their local repo, trying a bunch of different things out. With a central repo system, the developer might hesitate to create so many branches on the server, since they don't want to clutter up the server with branches that only they care about, and that aren't likely to be merged into the code base in the end. Also, (I think) svn doesn't have the ability to obliterate (yet)... With git.. you can branch, do some funky experimental code, still enjoying the benefits of version control, and not think about who else is going to see your experimental code, that you might not want to have to explain to the team yet, until it looks like something you might keep and merge in. So essentially, branching and merging becomes a much more natural and casual thing to do with a distributed system. Cheers, Rajesh Duggal. e.g.
Let’s say you’ve got 5 developer’s. With a distributed repo.. each developer can create as many branches as they want in their local repo, trying a bunch of different things out.

With a central repo system, the developer might hesitate to create so many branches on the server, since they don’t want to clutter up the server with branches that only they care about, and that aren’t likely to be merged into the code base in the end.

Also, (I think) svn doesn’t have the ability to obliterate (yet)…

With git.. you can branch, do some funky experimental code, still enjoying the benefits of version control, and not think about who else is going to see your experimental code, that you might not want to have to explain to the team yet, until it looks like something you might keep and merge in.

So essentially, branching and merging becomes a much more natural and casual thing to do with a distributed system.

Cheers,
Rajesh Duggal.

]]> By: Tim Dysinger http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-20071 Tim Dysinger Sat, 16 Feb 2008 10:39:38 +0000 http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-20071 You are not really "git"ing the point of git. You did mention fast, easy branching and distributed. But then you go into "My Views" and say that subversion can branch easy too (which I disagree with). Subversion branches have to happen on the server and then have to be re-downloaded again to the developer. Then they might propagate to ALL developer's machines depending on how much of the SVN tree they have checked out. Git branching happens in microseconds. Subversion has so many flaws in it's repository format too. Read here about Repository Formats Mattering http://keithp.com/blogs/Repository_Formats_Matter/ They do! Most projects are 50% the size of subversion repositories. As to your argument about 500 commits at once. It's just a matter of education. You could take all 500 of those commits and roll them up as one with git merge --squash Git, BZR, HG - they are all the wave of the future. Resistance is futile. Git is just one of the 1st. :) You are not really “git”ing the point of git. You did mention fast, easy branching and distributed. But then you go into “My Views” and say that subversion can branch easy too (which I disagree with). Subversion branches have to happen on the server and then have to be re-downloaded again to the developer. Then they might propagate to ALL developer’s machines depending on how much of the SVN tree they have checked out. Git branching happens in microseconds.

Subversion has so many flaws in it’s repository format too. Read here about Repository Formats Mattering http://keithp.com/blogs/Repository_Formats_Matter/ They do! Most projects are 50% the size of subversion repositories.

As to your argument about 500 commits at once. It’s just a matter of education. You could take all 500 of those commits and roll them up as one with git merge –squash

Git, BZR, HG - they are all the wave of the future. Resistance is futile. Git is just one of the 1st.

:)

]]> By: Rails Podcas... http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-19692 Rails Podcas... Thu, 07 Feb 2008 12:34:19 +0000 http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-19692 [...] All That Git Talk in The Rails World, What Gives? [...] [...] All That Git Talk in The Rails World, What Gives? [...]

]]> By: Tobias http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-19664 Tobias Wed, 06 Feb 2008 17:00:09 +0000 http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-19664 I think the problem you describe with the revision number bumping up 200% is a matter of bad source control practice. You would have experienced the same bump if the developer had committed each time to Subversion as well -- just over a longer period of time, but the end result would be the same. Ie. the problem seems to be too many small commits. But perhaps the design of Git is inviting to that kind of behavior a little more than SVN etc. I think the problem you describe with the revision number bumping up 200% is a matter of bad source control practice. You would have experienced the same bump if the developer had committed each time to Subversion as well — just over a longer period of time, but the end result would be the same.
Ie. the problem seems to be too many small commits.
But perhaps the design of Git is inviting to that kind of behavior a little more than SVN etc.

]]> By: AkitaOnRails http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-19662 AkitaOnRails Wed, 06 Feb 2008 16:43:10 +0000 http://www.danielfischer.com/2008/02/01/all-that-git-talk-in-the-rails-world-what-gives/#comment-19662 Nice discussion on Git. Let me showcase something that I did just this week that would be a pain to do in SVN but was trivial to do with Git. I had a blog hosted over Mephisto 0.7.3. I am using the SVN server of my hosting service. Capistrano to deploy, all good and dandy. Finally Rick Olson annouces Mephisto 0.8. Great! I have to have it! But ... how?? I've made a few changes, tweaked here and there. And one good news: Mephisto is now hosted over Git, so I just clone it. Then I clone my SVN repository using Git-SVN (and this is one hella of a nice tool). Finally, I merge both branches. Lot's of conflicts, that's for sure. But from now on I have a common ancestor to both branches and the next merges should be trivial. Sometimes I am not a hacker good enough to send things back to the original master, or I just made changes that matters to my work (like my blog), so I maintain 2 different branches: one with the original source, and the other with all my changes. I can now just merge everything from the master, or cherry-pick just the changes I need, and Git makes it utter trivial to do so. Nice discussion on Git. Let me showcase something that I did just this week that would be a pain to do in SVN but was trivial to do with Git.

I had a blog hosted over Mephisto 0.7.3. I am using the SVN server of my hosting service. Capistrano to deploy, all good and dandy.

Finally Rick Olson annouces Mephisto 0.8. Great! I have to have it! But … how?? I’ve made a few changes, tweaked here and there.

And one good news: Mephisto is now hosted over Git, so I just clone it. Then I clone my SVN repository using Git-SVN (and this is one hella of a nice tool). Finally, I merge both branches. Lot’s of conflicts, that’s for sure. But from now on I have a common ancestor to both branches and the next merges should be trivial.

Sometimes I am not a hacker good enough to send things back to the original master, or I just made changes that matters to my work (like my blog), so I maintain 2 different branches: one with the original source, and the other with all my changes. I can now just merge everything from the master, or cherry-pick just the changes I need, and Git makes it utter trivial to do so.

]]>