4 ms·

I have, and at least at my work, it's terrible. Sometimes it gets to the point where my submit requests time out several tries in a row. Yes, I'm sure it's beca

I have, and at least at my work, it's terrible. Sometimes it gets to the point where my submit requests time out several tries in a row. Yes, I'm sure it's because the people maintaining the server aren't doing it properly, but that's sort of the point. With git, you don't have to worry about it.

Xylakant 12y ago
> With git, you don't have to worry about it. Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.
- icefox 12y ago
  But at least you can run git log and not have to wait minutes.
  - Xylakant 12y ago
    True. You are spared some of the pain, but not all of it.
  - konstruktor 12y ago
    Ironically, Perforce doesn't even have proper search in commit history when it's working as designed. No need for the server to break...
- deathanatos 12y ago
  > Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly. But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.) With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)
  - Xylakant 12y ago
    The GP's words were: "With git, you don't have to worry about it." I never said that perforce would perform in any way better, but I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around. Try pushing your changes via email to your CI server. Fully decentralized would be beautiful, but I seriously don't see many teams that use git (or any other system) in that manner. Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is.
    - deathanatos 12y ago
      I was responding to you. :-) > I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around. I agree. The first time I read your argument, I interpreted it as a reason to not use git itself, but I think we're on the same page. > Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is. What else can be done? I don't really want to push changes to my co-workers individually, I want a place to push changes that any co-worker can then pull from — do I not? Toward this goal, certainly I could create n servers, and make pushing redundant over those n servers, have then do consensus to agree on HEAD, etc., but that seems to me to be what I'm paying GitHub to do.
- lmm 12y ago
  There are good managed git services for companies that don't want to run their own. If my sysadmins are truly incompetent I can use a free private bitbucket repository.
- HelloNurse 12y ago
  If Git pushes start failing randomly, it isn't even a failure: no file has been harmed, and a new central "server" can be freely improvised.

Xylakant 12y ago

> With git, you don't have to worry about it. Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.

icefox 12y ago
But at least you can run git log and not have to wait minutes.
- Xylakant 12y ago
  True. You are spared some of the pain, but not all of it.
- konstruktor 12y ago
  Ironically, Perforce doesn't even have proper search in commit history when it's working as designed. No need for the server to break...
deathanatos 12y ago
> Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly. But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.) With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)
- Xylakant 12y ago
  The GP's words were: "With git, you don't have to worry about it." I never said that perforce would perform in any way better, but I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around. Try pushing your changes via email to your CI server. Fully decentralized would be beautiful, but I seriously don't see many teams that use git (or any other system) in that manner. Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is.
  - deathanatos 12y ago
    I was responding to you. :-) > I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around. I agree. The first time I read your argument, I interpreted it as a reason to not use git itself, but I think we're on the same page. > Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is. What else can be done? I don't really want to push changes to my co-workers individually, I want a place to push changes that any co-worker can then pull from — do I not? Toward this goal, certainly I could create n servers, and make pushing redundant over those n servers, have then do consensus to agree on HEAD, etc., but that seems to me to be what I'm paying GitHub to do.
lmm 12y ago
There are good managed git services for companies that don't want to run their own. If my sysadmins are truly incompetent I can use a free private bitbucket repository.
HelloNurse 12y ago
If Git pushes start failing randomly, it isn't even a failure: no file has been harmed, and a new central "server" can be freely improvised.