3 ms·

> More seriously, it sounds like someone who had a bad experience with Git at one point got put in an undeserved position of power in which they got to enforce

by nupark2 15y ago

> More seriously, it sounds like someone who had a bad experience with Git at one point got put in an undeserved position of power in which they got to enforce the results of that bad experience on everyone else. I set technical direction and while using git isn't a firable offense, we will never support it as the official SCM system. The reason is quite simple: in a centralized environment, it increases costs and complexity and provides no value to offset that. We don't want: - People hiding their work in local branches where none of the other engineers can follow along. - Getting massive rebased commits once every day (or worse yet, every few days). - An open-source Linux-inspired development model consisting of a massively distributed ecosystem of competing/disparate/intertwined branches.

JoshTriplett 15y ago
There's a big difference between "not the official SCM system" and "a fireable offence". As a developer, I frequently use a pile of tools that don't have official support, because they help me get my job done more effectively than the "official" tools. Sometimes those end up becoming the official tools later, sometimes they don't. But in any case, some of the issues you've listed represent bugs in development processes, not in Git. > - People hiding their work in local branches where none of the other engineers can follow along. Good developers using Git don't "hide their work" in local branches any more than they "hide their work" in an editor before they save it; sometimes you just have work in progress that shouldn't get pushed yet. (I certainly hope you have policies about when to commit, which include things like "the code compiles" or "passes tests" or "smells right"; if so, why aren't you concerned about people "hiding their work" in their uncommitted working copies?) If that work in progress has a sufficiently large scope that it needs more developers involved, then the branch may want to live in a repository accessible to others. Before I had git-svn, when I had to work with SVN repositories, I ended up having several local copies of the repository, and doing the "small self-contained commits" thing manually by copying bits into and out of working copies. Git provided much more structure to that process, as well as making it faster and more efficient. > - Getting massive rebased commits once every day (or worse yet, every few days). Don't do that. You can and should push arbitrarily often. > - An open-source Linux-inspired development model consisting of a massively distributed ecosystem of competing/disparate/intertwined branches. If you have a project anywhere near as large as the Linux kernel, you'd be lucky to end up that well organized and optimized. But while you still have a team that can regularly communicate with each other on a list low-volume enough for people to read all the mails, you don't really need that ecosystem of hierarchical branches and repositories; nonetheless, you can get a lot of value out of Git even when using it with a single central repository.
aeontech 15y ago
> "... 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.

by nupark2 15y ago

JoshTriplett 15y ago

There's a big difference between "not the official SCM system" and "a fireable offence". As a developer, I frequently use a pile of tools that don't have official support, because they help me get my job done more effectively than the "official" tools. Sometimes those end up becoming the official tools later, sometimes they don't. But in any case, some of the issues you've listed represent bugs in development processes, not in Git. > - People hiding their work in local branches where none of the other engineers can follow along. Good developers using Git don't "hide their work" in local branches any more than they "hide their work" in an editor before they save it; sometimes you just have work in progress that shouldn't get pushed yet. (I certainly hope you have policies about when to commit, which include things like "the code compiles" or "passes tests" or "smells right"; if so, why aren't you concerned about people "hiding their work" in their uncommitted working copies?) If that work in progress has a sufficiently large scope that it needs more developers involved, then the branch may want to live in a repository accessible to others. Before I had git-svn, when I had to work with SVN repositories, I ended up having several local copies of the repository, and doing the "small self-contained commits" thing manually by copying bits into and out of working copies. Git provided much more structure to that process, as well as making it faster and more efficient. > - Getting massive rebased commits once every day (or worse yet, every few days). Don't do that. You can and should push arbitrarily often. > - An open-source Linux-inspired development model consisting of a massively distributed ecosystem of competing/disparate/intertwined branches. If you have a project anywhere near as large as the Linux kernel, you'd be lucky to end up that well organized and optimized. But while you still have a team that can regularly communicate with each other on a list low-volume enough for people to read all the mails, you don't really need that ecosystem of hierarchical branches and repositories; nonetheless, you can get a lot of value out of Git even when using it with a single central repository.

aeontech 15y ago

> "... 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.