This is the killer feature for Git, because many of us, the newcomers, like me, will want to experiment a little before submitting a patch. This way, I can create a local branch and I'm free to do whatever I want. The SVN branch is visible on the server, I don't want to publish my crappy code before I feel that the feature or the bugfix has high quality and is readable enough.
Regards, Silviu On Tue, Sep 9, 2014 at 9:12 PM, Mark Fortner <phidia...@gmail.com> wrote: > Paul, > Git branching is faster, computationally cheaper, and requires less disk > space than svn branching. This link provides more information: > https://git.wiki.kernel.org/index.php/GitSvnComparison. > > In git, you have a remote repo, and a local repo. Typically, people create > local branches for experiments or new features and then merge and create > pull-requests whenever they have something that they want to share with the > community. In svn, whenever you branch, you're branching on the server > first. Usually, if you're new to a code base, you don't want to do that if > you're just experimenting. Ideally, you want to encourage experimentation > (and attract new developers), so "feature branches" make a lot of sense in > that context. > > Cheers, > > Mark > > > > On Tue, Sep 9, 2014 at 10:46 AM, Paul Benedict <pbened...@apache.org> > wrote: > > > Mark, can you help me understand why git branches (the "feature" branch) > is > > better than an svn branch? > > > > > > Cheers, > > Paul > > > > On Tue, Sep 9, 2014 at 10:57 AM, Mark Fortner <phidia...@gmail.com> > wrote: > > > > > If I had to pick one feature that makes git more useful than svn, it > > would > > > be the ease in creating feature branches. If you want to add a > feature, > > > you simply create a local branch to implement the feature, implement > it, > > > and commit it, and create a pull request. If you're using Atlassian's > > > Crucible or Stash, it's pretty easy to do a code review of the pull > > > request. > > > > > > Feature branching makes it easy for developers to get their feet wet > > with a > > > code base. You can try out experiments. Have branches for each > > experiment. > > > It makes it easier to attract new developers to a project. > > > > > > From the previous discussion thread, it seems like the main objections > > were > > > (paraphrasing a bit here): > > > > > > - I'm not familiar with git. I've got a process that works for me > and > > I > > > don't want to change it. > > > - I don't see the value in it. > > > - We don't know the impact on the release process. > > > > > > > > > In order to address these concerns, it makes sense to try it out on a > > > project. The next question is -- which project. The project needs to > be > > > central enough that everyone has some skin in the game. It should be a > > > project that you have an interest in. If you haven't used git before, > > then > > > you need to try implementing a feature in that project. The project > lead > > > should also be someone who's familiar with git, and feels comfortable > > with > > > answering questions about git. > > > > > > I think if we can identify a project, and get commitment from everyone > > who > > > hasn't tried git, to add a small feature, add some comments, or add a > > unit > > > test, we'll learn enough. The project lead can look at the impact on > the > > > release process, and report any findings. At least at that point, > we'll > > > have learned enough from the process to make an informed decision. > > > > > > > > > Regards, > > > > > > Mark > > > > > > > > > > > > On Tue, Sep 9, 2014 at 8:27 AM, Emmanuel Bourg <ebo...@apache.org> > > wrote: > > > > > > > Le 09/09/2014 16:52, Paul Benedict a écrit : > > > > > Is there an itch to scratch (need) by moving to git as opposed to > > just > > > > > continue using svn? > > > > > > > > I guess the "itch" is simply an increasing preference for Git among > the > > > > people involved here. I don't think the migration will fix any > > important > > > > problem. > > > > > > > > Emmanuel Bourg > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > -- - OCPJP7 (90%) - OCAJP7 (93%) - Java and Big Data Enthusiast
