[Rygian]

> This is mostly a configuration issue. I guess this was done by a force push command. IFAIK, you can disable force push by configuration.

If a feature can lead to actual unintended data loss, it should come disabled by default. Are there any other "unsafe by default" features in Git? What would be a sane general default that prevents unwanted data loss, and why is it the case?

[guax]

--force always imply data loss. You're overriding the remote state.

Do people use it in an unsafe manner because they don't understand git and there lies a problem that could be tackled? yes.

With that, I don't think git has any feature that is unsafe by default.

[sasham]

In that specific case there was some error that the user didn't understand, he googled and found a StackOverflow answer with --force. And naturally tried it BitBucket didn't have branch protection back then, today it's a bit better (you can still destroy your work but usually not others')

[Einenlum]

I agree that git is very complex (just try reading its documentation and how many options or commands you have never heard of before). But I think push --force is probably one of the easiest git concepts to get. The fact that someone in your team copy pasted something from SO without understanding it doesn't seem to be related to git. Otherwise we could say that the fact some people lose their data through "sudo rm -rf /" proves the complexity of Unix. I don't think so.

[nullstyle]

This was Pebcac my dude. git wasn’t at fault here, the script kiddy that pastes before understanding is the fault. Amateurs

[CJefferson]

My biggest problem with git is branch deletion — if you never do it you end up with far too many, but deleting a branch can’t be version controlled.

[renewiltord]

It is somewhat version-controlled but not completely. If you use the reflog you can find it again and you can find how it moved around. But the reflog gets rewritten and gc'd so it's not true vc.

[AdityaSanthosh]

Just curious, why do you want that to be version controlled?

[CJefferson]

Because I might realize later I made a mistake, or I might want to view history.

I’d I never cared about historical state and mistakes, I wouldn’t need version control at all :)

[couchand]

You could delete the branches locally while archiving them to any another clone of the repo.

[IshKebab]

> With that, I don't think git has any feature that is unsafe by default.

Well, you just mentioned `--force`. It is unsafe by default. Git has a couple of flags to make it safer (`--force-with-lease`, `--force-if-includes`) but those aren't the default.

[withinboredom]

If you’ve ever had to remove private information from history before making the repos public (think domains, names, configuration, etc) you will appreciate the ability to rewrite history (and all the other things --force gives you)

[IshKebab]

I don't get your point. Nobody is saying don't use `--force`. Just that the default `--force` flag is the most dangerous variant.

[withinboredom]

I am not aware of any default use of force. Where does that happen?

[kristjansson]

The feature is 'git push'. --force is the opt-in to the unsafe behavior. It should not be used lightly.

[IshKebab]

You're missing the point. `--force` is the default of the force variants. The other `--force-but-something` arguments clearly modify that default. It's the wrong way round.

Obviously they've done it for backwards compatibility, but the fact that they haven't even added an option to make it the default is pretty lame.

[couchand]

Should a chain saw come with the ability to start the engine disabled by default?

[IshKebab]

Yes. That is a great idea. You could do something like a tab that you have to remove that tells you about chainsaw safety.

[couchand]

The problem here is not the tool. The problem is the author's colleague's willingness to paste a stackoverflow answer into their terminal without taking a moment to understand what it does.

If stackoverflow told them to break off the chainsaw safety tab there is no chance it would have been read first.

[dmazzoni]

But it doesn't lead to data loss.

The commits that were overwritten by "force" are still there on the server. Any admin could recover them pretty easily. They're probably still present in the local repo of the person who ran "git push --force" too, as well as anyone else's machine who has cloned the repo.

The only way you'd actually lose data is if every single person who had a clone of the repo ran gc.

Or apparently if nobody knew about "git reflog" and nobody bothered to do a Google search for "oops I accidentally force pushed in git" to learn how to fix it.