Re:Moving from SVN to Git in 1,000 easy steps
by nupark2 on Saturday December 03, 2011 @10:02AM
(#3307859)
The problems you described are failures of workflow due to bad process and/or bad developer education, _not_ failures inherent in the design of any given distributed VCS. I have never had to deal with any of those issues, because we have always ensured that we have a good workflow in place.
Most of the features you're discussing encourage that workflow/bad process/bad developer behavior, because they were built entirely to support Linux's development methodology in which that behavior isn't not considered a hindrance.
Re:Moving from SVN to Git in 1,000 easy steps
by aeontech on Sunday December 04, 2011 @01:33AM
(#3310041)
Like I said, neither I, nor my team mates had issues that you describe, nor do I see evidence of this behaviour in Linux development methodology from what I read on the mailing lists. Just because a suboptimal workflow may be created with git, it does not mean you should forgo its power altogether - in fact, one of the main "features" of git that people describe is that it can support more than one way of working in a team.
However, you clearly have your mind made up, so, let us leave it at that.
That right there, tells me that you have never actually used git in a team environment with a good workflow enough to actually learn about its advantages and disadvantages. Sure, git is not perfect, but to boldly say that it offers no value in a centralized environment is, ah, how shall I say it... self-assured to the point of trollishness.
I, and many many other people have used git for years, both in centralized environments and not, and I can tell you that git (and more broadly, any decentralized VCS) has tons of useful features in a centralized environment compared to SVN/CVS and their ilk. Just off the top of my head, features I could not live without now:
- much more powerful branch merge tracking
- much better conflict resolution compared to CVS/SVN.
- partial commits
- history rewriting (massively useful in cleaning up before pushing) - ability to work without network connection
- ability to cherry pick commits between branches
The problems you described are failures of workflow due to bad process and/or bad developer education, _not_ failures inherent in the design of any given distributed VCS. I have never had to deal with any of those issues, because we have always ensured that we have a good workflow in place.