4 ms·

> "... provides no value to offset that." That right there, tells me that you have never actually used git in a team environment with a good workflow enough to

> "... provides no value to offset 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.

nupark2 15y ago
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.
- aeontech 15y ago
  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.

nupark2 15y ago

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.

aeontech 15y ago
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.