5 ms·

Where I work we just moved off Git to TFS. Our coders had a lot of trouble understanding Git, actually our whole company has had trouble with Git. We decided to

Where I work we just moved off Git to TFS. Our coders had a lot of trouble understanding Git, actually our whole company has had trouble with Git. We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. We moved into TFS, and while we're working to get our DLLs to not be circularly referencing, we have an actually verifiable copy of our source code. Maybe it's because we use MS technologies (IIS, .NET, MSSQL) but we were on TFS in a matter of weeks while Git still confused us after a month of use. Many of my coworkers feel it's a "piece of Git" (if you get my expletive). Several also think it's a waste of time. I don't disagree with them. I supported Git because I saw it on here. This solution doesn't our solve problems in our situation.

j_s 12y ago
Thank you for taking the time to share your anecdote, even if it is an unpopular one here. I hope Hacker News readers are understanding enough to recognize the need for buy-in from developers, and the necessity of a reasonable level of expertise when leading the switch to a distributed source control system. Sorry things didn't work out for your team; TFS branching and merging is so much more painful!
orkoden 12y ago
>We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. You can configure your server to not accept certain commands and restrict pushing branches to certain users. Also if you do wipe your repository, restore it form your backup.
- stephengillie 12y ago
  What backup? You mean we have to manually back up this system? Why should we have to spend money (aka devops man-hours) developing a backup system, when other Source Version Control systems don't let individual coders blow away the Source? EDIT: For those unclear, we almost had to pull our backup of Source out of Glacier because someone deleted our local repository. We weren't expecting to need to set up permissions for things that should be assumed out of the box.
  - aeon10 12y ago
    git is a distributed system. Everyone else has a full copy of the repository. therefore everyone actually has a backup.
    - stephengillie 12y ago
      Everyone else only has a full copy of the repository if they actually check out a copy and keep it local. That's apparently not how my coders do their workflow.
      - peterwwillis 12y ago
        If all your coders are editing files in one single directory all at the same time, well, that's pretty crazy. Not even CVS forces you to all work out of the same directory; it lets you check out your own local working copy and push changes to the server. Git is almost the same from the user's perspective, with the noted difference that you get an entire copy of the repo and not just one working copy of some of the files.
      - seren 12y ago
        The most usual way to work with git is to pull a local copy of the whole server using "git clone"[1]. The only way to do a partial copy would be to do a shallow copy locally with only the last few commits, but then it will probably be harder to merge back... So it seems you are either wrong, or that your team is using a very very exotic workflow. [1] it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
      - ori_b 12y ago
        What?!? Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? Why?
        dragonwriter 12y ago
        > Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? You can use git for version control without a full repository copy -- you can git clone with limited depth, for instance.
pyre 12y ago
This: > This solution doesn't our solve problems in our situation. is a far cry from: > Many of my coworkers feel it's a "piece of Git" (if you get my expletive). Just sayin'. It's the same attitude that once caused an obnoxious movie-goer to get all hot and bothered (yelling at the screen, trying to explain it to his date, etc) over seeing a Mac on-screen because "it would have gone a lot faster if he was using a PC."
- stephengillie 12y ago
  What are you just saying? I used both of those statements in the same paragraph to express my sentiment. And some anecdote about some movie-goer being upset in front of his date? Are you accusing me of fanboyism for saying one solution didn't solve my team's problem, while the other does?
  - pyre 12y ago
    I'm saying that "doesn't solve my problems" != "a piece of 'git'"
eddiedunn 12y ago
> We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. What? 1) You can configure your repo so only select users may use destructive commands on certain branches. 2) It's a _distributed_ content versioning system. Even if someone wiped out the main, "central", repository, all users will have a full local copy, a backup in effect. Git has a horrible UI in many ways, but your apparent dislike of it smells more of incompetence and a naive buy-in of the full Microsoft ecosystem than anything else. BTW, I didn't know what TFS was before checking on Wikipedia, but -- somewhat ironcially given your gripe -- TFS seems to have decent support for Git[1]. [1]: https://en.wikipedia.org/wiki/Team_Foundation_Server#Git https://en.wikipedia.org/wiki/Team_Foundation_Server#Git [EDIT]: formatting
- stephengillie 12y ago
  1. Some of this does look like ignorance on the part of my coworker who set up both. But why isn't that a default setting? Why give that permission to all users? 2. This is true only if other users keep local copies of the main repository, keep it updated, and don't mix it in with their code. You're making a lot of assumptions.
  - joeriel 12y ago
    Your second statement shows a complete lack of understanding of VCS in general.
  - eddiedunn 12y ago
    1. When I set up Git on my Linux server only the user that initiated the repo had access to it. It was too locked down, seeing as external users didn't even have read/cloning permission. (A minimal amount of googling solved all my problems, though.) Your problem sounds to me as another PEBCAC on the part of your coworker. 2. I'm not making all the assumptions you claim. First of all, as soon as you clone a repo you have a local copy. You need this clone in order to be able to even work with the code, so it would be quite weird if employees deleted their clone after editing, committing, and pushing their changes. I'm not even sure what you mean with "mix it in with their code". It's a VCS -- if you don't like a change reverting it is trivial. All in all, I understand why users might have problems with Git. It has a steep learning curve. I think it has a horrible command line UI. It might not have worked well for your company, even if you had a competent admin set up the repos. However, I would prefer if you could argue your point based on the actual merits and faults of Git, rather than based on ignorance.

j_s 12y ago

Thank you for taking the time to share your anecdote, even if it is an unpopular one here. I hope Hacker News readers are understanding enough to recognize the need for buy-in from developers, and the necessity of a reasonable level of expertise when leading the switch to a distributed source control system. Sorry things didn't work out for your team; TFS branching and merging is so much more painful!

orkoden 12y ago

>We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. You can configure your server to not accept certain commands and restrict pushing branches to certain users. Also if you do wipe your repository, restore it form your backup.

stephengillie 12y ago
What backup? You mean we have to manually back up this system? Why should we have to spend money (aka devops man-hours) developing a backup system, when other Source Version Control systems don't let individual coders blow away the Source? EDIT: For those unclear, we almost had to pull our backup of Source out of Glacier because someone deleted our local repository. We weren't expecting to need to set up permissions for things that should be assumed out of the box.
- aeon10 12y ago
  git is a distributed system. Everyone else has a full copy of the repository. therefore everyone actually has a backup.
  - stephengillie 12y ago
    Everyone else only has a full copy of the repository if they actually check out a copy and keep it local. That's apparently not how my coders do their workflow.
    - peterwwillis 12y ago
      If all your coders are editing files in one single directory all at the same time, well, that's pretty crazy. Not even CVS forces you to all work out of the same directory; it lets you check out your own local working copy and push changes to the server. Git is almost the same from the user's perspective, with the noted difference that you get an entire copy of the repo and not just one working copy of some of the files.
    - seren 12y ago
      The most usual way to work with git is to pull a local copy of the whole server using "git clone"[1]. The only way to do a partial copy would be to do a shallow copy locally with only the last few commits, but then it will probably be harder to merge back... So it seems you are either wrong, or that your team is using a very very exotic workflow. [1] it is explicitly called clone and not checkout to underline the fact that you are actually replicating all the data of the server.
    - ori_b 12y ago
      What?!? Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? Why?
      - dragonwriter 12y ago
        > Git forces you to check out a copy in order to be fully functional. Are you saying they're working without version control? You can use git for version control without a full repository copy -- you can git clone with limited depth, for instance.

pyre 12y ago

This: > This solution doesn't our solve problems in our situation. is a far cry from: > Many of my coworkers feel it's a "piece of Git" (if you get my expletive). Just sayin'. It's the same attitude that once caused an obnoxious movie-goer to get all hot and bothered (yelling at the screen, trying to explain it to his date, etc) over seeing a Mac on-screen because "it would have gone a lot faster if he was using a PC."

stephengillie 12y ago
What are you just saying? I used both of those statements in the same paragraph to express my sentiment. And some anecdote about some movie-goer being upset in front of his date? Are you accusing me of fanboyism for saying one solution didn't solve my team's problem, while the other does?
- pyre 12y ago
  I'm saying that "doesn't solve my problems" != "a piece of 'git'"

eddiedunn 12y ago

> We decided to leave it when we realized any individual coder could wipe out our local repository with a wrong command. What? 1) You can configure your repo so only select users may use destructive commands on certain branches. 2) It's a _distributed_ content versioning system. Even if someone wiped out the main, "central", repository, all users will have a full local copy, a backup in effect. Git has a horrible UI in many ways, but your apparent dislike of it smells more of incompetence and a naive buy-in of the full Microsoft ecosystem than anything else. BTW, I didn't know what TFS was before checking on Wikipedia, but -- somewhat ironcially given your gripe -- TFS seems to have decent support for Git[1]. [1]: https://en.wikipedia.org/wiki/Team_Foundation_Server#Git https://en.wikipedia.org/wiki/Team_Foundation_Server#Git [EDIT]: formatting

stephengillie 12y ago
1. Some of this does look like ignorance on the part of my coworker who set up both. But why isn't that a default setting? Why give that permission to all users? 2. This is true only if other users keep local copies of the main repository, keep it updated, and don't mix it in with their code. You're making a lot of assumptions.
- joeriel 12y ago
  Your second statement shows a complete lack of understanding of VCS in general.
- eddiedunn 12y ago
  1. When I set up Git on my Linux server only the user that initiated the repo had access to it. It was too locked down, seeing as external users didn't even have read/cloning permission. (A minimal amount of googling solved all my problems, though.) Your problem sounds to me as another PEBCAC on the part of your coworker. 2. I'm not making all the assumptions you claim. First of all, as soon as you clone a repo you have a local copy. You need this clone in order to be able to even work with the code, so it would be quite weird if employees deleted their clone after editing, committing, and pushing their changes. I'm not even sure what you mean with "mix it in with their code". It's a VCS -- if you don't like a change reverting it is trivial. All in all, I understand why users might have problems with Git. It has a steep learning curve. I think it has a horrible command line UI. It might not have worked well for your company, even if you had a competent admin set up the repos. However, I would prefer if you could argue your point based on the actual merits and faults of Git, rather than based on ignorance.