> 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.)
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.
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.
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.
> "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.
* 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.
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.
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?"
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.
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.
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.
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?
* 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...