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

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?

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.

I bet they are willfully blind to that difference.

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

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.

> "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 doesn't say Microsoft or IBM

GitHub does, now, though I really hope that isn’t necessary for a company to adopt version control.

And Visual Source Safe and TFS did previously.

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/

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

Oh and this is on prem...

https://azure.microsoft.com/en-us/services/devops/server/

On prem gitlab then? Just throwing out ideas.

There are self hosted Azure products also.

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.

What else are you gonna use? SVN? shudder

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.

There's also this which is fantastically named! https://ohshitgit.com

> 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?

OK.