7 ms·

> What's are the arguments against version control here (if any)? * I don't understand it * You're overcomplicating things * We're not using any of that free

> What's are the arguments against version control here (if any)? * I don't understand it * You're overcomplicating things * We're not using any of that free shit here * It doesn't say Microsoft or IBM * The last guy we hired that tried to use it was smarter than I was so anyone else who tries is a threat to my leadership. (because everyone knows you can only manage people who have a strict subset of your own knowledge. If one of your peons dared learn something before you, that would be the end of your reign.) the list goes on...

ken 7y ago
> It doesn't say Microsoft or IBM GitHub does, now, though I really hope that isn’t necessary for a company to adopt version control.
- deleted 7y ago
  [deleted]
- dragonwriter 7y ago
  And Visual Source Safe and TFS did previously.
skellera 7y ago
Why didn’t you just recommend Azure Repos? It’s a great product and fits what you need. https://azure.microsoft.com/en-au/services/devops/repos/ https://azure.microsoft.com/en-au/services/devops/repos/
- reificator 7y ago
  * Azure means cloud and cloud means no * It didn't exist at the time, but there was an on-prem that MS offered a few years back. It was forced on another department with no version control experience. It lasted about two weeks.
  - eberkund 7y ago
    There are self hosted Azure products also.
  - skellera 7y ago
    On prem gitlab then? Just throwing out ideas.
  - skellera 7y ago
    Oh and this is on prem... https://azure.microsoft.com/en-us/services/devops/server/ https://azure.microsoft.com/en-us/services/devops/server/
perl4ever 7y ago
I'm not sure what the answer is for version control, but I refuse to accept it's Git. I don't understand how it became so popular - did nobody say "wait, there might be a reason why Linus is known for cloning an OS and not coming up with a brilliant design for one from scratch?"
- misterdoubt 7y ago
  OK.
- bmn__ 7y ago
  > I don't understand how it became so popular Git follows in spirit the model of BitKeeper, a software that already worked exceptionally well for Linus and other kernel devs. So Git had both a known good design from the very beginning and a decently sized installed user base (kernel devs) with an important project (the kernel). IMO there's nothing wrong with the cloning of software. You make it sound bad, can you give reasons?
- benbristow 7y ago
  Git is great. Lightweight, scales effortlessly, learning curve isn’t too bad, decentralised by design and because it’s so widely adopted it works pretty much everywhere. What else are you gonna use? SVN? shudder
  - perl4ever 7y ago
    The learning curve isn't too bad? Do you actually use Git? Like, from the command line? I have no issue with a friendly wrapper in general, but after starting with the basic interface, I don't trust a wrapper to be logical, complete, and well thought out, given the foundation.
    - benbristow 7y ago
      Yes, I use Git mainly from the command line and I've used it on Linux, OSX and Windows. I've also used quite a few GUIs including SourceTree, Github Desktop and GitKraken. I've been using it for a while now! In the end it really boils down to a few commands that you use often, checkout/push/pull/commit/clone/branch/diff/status etc. It can definitely get confusing at times when you get merge conflicts and want to start playing with rebasing and stuff like that. I've used it with teams with no experience with Git whatsoever and they're usually fluent at the basics within a week or so. If you get stuck the command you need is usually a 2 minute Google away. There's also this which is fantastically named! https://ohshitgit.com https://ohshitgit.com
Chirael 7y ago
“We’ve never needed it before, so why do we need it now?” (actual argument against it at my current workplace)
- reificator 7y ago
  My response: You've never looked at a piece of code that you wanted to see the history of? You've never needed to revert a single change a few hours/days/weeks later? You've never needed to track down the person who wrote a piece of code in order to ask them for clarification? You've never needed to see the original change reason for a line of code that is doing some weird, specific thing that seems out of place? You've never needed to have two people edit the same file at the same time?
  - crististm 7y ago
    I've got these responses on a similar question: "we don't need to see the commit logs so who cares about them or the history being pretty and clear? Nobody is looking at the history!"!! The question was "Let's submit pull requests as a clean job not as a homework draft. Why don't we allow push force on work branches so that we can squash fixup commits after review?" Blows my mind that those are senior developers that are otherwise seemingly competent at what they do. There is some pinch of job security there though.
    - bmarkovic 7y ago
      There are valid reasons for a "never rewrite history" policy, but their validity pales further you go from the master branch. The thing is that in a lot of scenarios people need to do huge chunks of work in feature branches. Sometimes a 3000 line "refactor the world" squashed commit is really unhelpful. The best policy is always well thought of weighted case-by-case decisions. However, on projects with a lot of hands on the keyboard such policy is unrealistic and someone will do the opposite of what they should and wont ask or discuss. People, especially in our business, hide incompetence behind aloofness and silence. So in that case, with a lot of people that are hard to manage, stiff policy is the best choice and there probably are reasons why people want to preserve history, no matter how hairy it looks, at least it's there and you can find stuff in it.
AlexCoventry 7y ago
* Someone used git to publish a HIPAA violation on github.
- reificator 7y ago
  If HIPAA is a concern host your own server. If you can't trust your employees to adhere to HIPAA or other mandatory regulations, you need better employees. If your source code contains personal information, usernames, passwords, etc that should not be exposed to the public, you need to address that immediately regardless of any irrational stances on version control.
  - mcv 7y ago
    > "If you can't trust your employees to adhere to HIPAA or other mandatory regulations, you need better employees." You need a better process. Developers aren't lawyers. Of course they should be aware of HIPAA requirements, but better is to ensure they simply don't have access to sensitive production data except in very controlled circumstances, while making safe anonymised test data available for anything they need test data for.
scott_s 7y ago
I've learned there are arguments that are not worth winning, and if you find yourself in one, your priority should be getting out of the situation that created the argument.

ken 7y ago

> It doesn't say Microsoft or IBM GitHub does, now, though I really hope that isn’t necessary for a company to adopt version control.

deleted 7y ago
[deleted]
dragonwriter 7y ago
And Visual Source Safe and TFS did previously.

skellera 7y ago

Why didn’t you just recommend Azure Repos? It’s a great product and fits what you need. https://azure.microsoft.com/en-au/services/devops/repos/ https://azure.microsoft.com/en-au/services/devops/repos/

reificator 7y ago
* Azure means cloud and cloud means no * It didn't exist at the time, but there was an on-prem that MS offered a few years back. It was forced on another department with no version control experience. It lasted about two weeks.
- eberkund 7y ago
  There are self hosted Azure products also.
- skellera 7y ago
  On prem gitlab then? Just throwing out ideas.
- skellera 7y ago
  Oh and this is on prem... https://azure.microsoft.com/en-us/services/devops/server/ https://azure.microsoft.com/en-us/services/devops/server/

perl4ever 7y ago

I'm not sure what the answer is for version control, but I refuse to accept it's Git. I don't understand how it became so popular - did nobody say "wait, there might be a reason why Linus is known for cloning an OS and not coming up with a brilliant design for one from scratch?"

misterdoubt 7y ago
OK.
bmn__ 7y ago
> I don't understand how it became so popular Git follows in spirit the model of BitKeeper, a software that already worked exceptionally well for Linus and other kernel devs. So Git had both a known good design from the very beginning and a decently sized installed user base (kernel devs) with an important project (the kernel). IMO there's nothing wrong with the cloning of software. You make it sound bad, can you give reasons?
benbristow 7y ago
Git is great. Lightweight, scales effortlessly, learning curve isn’t too bad, decentralised by design and because it’s so widely adopted it works pretty much everywhere. What else are you gonna use? SVN? shudder
- perl4ever 7y ago
  The learning curve isn't too bad? Do you actually use Git? Like, from the command line? I have no issue with a friendly wrapper in general, but after starting with the basic interface, I don't trust a wrapper to be logical, complete, and well thought out, given the foundation.
  - benbristow 7y ago
    Yes, I use Git mainly from the command line and I've used it on Linux, OSX and Windows. I've also used quite a few GUIs including SourceTree, Github Desktop and GitKraken. I've been using it for a while now! In the end it really boils down to a few commands that you use often, checkout/push/pull/commit/clone/branch/diff/status etc. It can definitely get confusing at times when you get merge conflicts and want to start playing with rebasing and stuff like that. I've used it with teams with no experience with Git whatsoever and they're usually fluent at the basics within a week or so. If you get stuck the command you need is usually a 2 minute Google away. There's also this which is fantastically named! https://ohshitgit.com https://ohshitgit.com

Chirael 7y ago

“We’ve never needed it before, so why do we need it now?” (actual argument against it at my current workplace)

reificator 7y ago
My response: You've never looked at a piece of code that you wanted to see the history of? You've never needed to revert a single change a few hours/days/weeks later? You've never needed to track down the person who wrote a piece of code in order to ask them for clarification? You've never needed to see the original change reason for a line of code that is doing some weird, specific thing that seems out of place? You've never needed to have two people edit the same file at the same time?
- crististm 7y ago
  I've got these responses on a similar question: "we don't need to see the commit logs so who cares about them or the history being pretty and clear? Nobody is looking at the history!"!! The question was "Let's submit pull requests as a clean job not as a homework draft. Why don't we allow push force on work branches so that we can squash fixup commits after review?" Blows my mind that those are senior developers that are otherwise seemingly competent at what they do. There is some pinch of job security there though.
  - bmarkovic 7y ago
    There are valid reasons for a "never rewrite history" policy, but their validity pales further you go from the master branch. The thing is that in a lot of scenarios people need to do huge chunks of work in feature branches. Sometimes a 3000 line "refactor the world" squashed commit is really unhelpful. The best policy is always well thought of weighted case-by-case decisions. However, on projects with a lot of hands on the keyboard such policy is unrealistic and someone will do the opposite of what they should and wont ask or discuss. People, especially in our business, hide incompetence behind aloofness and silence. So in that case, with a lot of people that are hard to manage, stiff policy is the best choice and there probably are reasons why people want to preserve history, no matter how hairy it looks, at least it's there and you can find stuff in it.

AlexCoventry 7y ago

* Someone used git to publish a HIPAA violation on github.

reificator 7y ago
If HIPAA is a concern host your own server. If you can't trust your employees to adhere to HIPAA or other mandatory regulations, you need better employees. If your source code contains personal information, usernames, passwords, etc that should not be exposed to the public, you need to address that immediately regardless of any irrational stances on version control.
- mcv 7y ago
  > "If you can't trust your employees to adhere to HIPAA or other mandatory regulations, you need better employees." You need a better process. Developers aren't lawyers. Of course they should be aware of HIPAA requirements, but better is to ensure they simply don't have access to sensitive production data except in very controlled circumstances, while making safe anonymised test data available for anything they need test data for.

scott_s 7y ago

I've learned there are arguments that are not worth winning, and if you find yourself in one, your priority should be getting out of the situation that created the argument.