I totally agree. This follows a long tradition of Git "fixing" things by adding a flag that 99% of users won't ever discover. They never fix the defaults.

And yes, you can fix defaults without breaking backwards compatibility.

▲

Jenk 5 days ago | parent [-]

> They never fix the defaults

Not strictly true. They did change the default push behaviour from "matching" to "simple" in Git 2.0.

▲

hinkley 5 days ago | parent [-]

So what was the second time the stopped watch was right?

I agree with GP. The git community is very fond of doing checkbox fixes for team problems that aren’t or can’t be set as defaults and so require constant user intervention to work. See also some of the sparse checkout systems and adding notes to commits after the fact. They only work if you turn every pull and push into a flurry of activity. Which means they will never work from your IDE. Those are non fixes that pollute the space for actual fixes.

▲

smohare 5 days ago | parent [-]

I’ve used git since its inception. Never once in an “IDE”. Should users that refuse to learn the tool really be the target?

I’m not trying to argue that interface doesn’t matter. I use jq enough to be in that unfortunate category where I despise its interface. But it is difficult for me to imagine being similarly incapable in git.

	▲	hinkley 4 days ago \| parent \| next [-]
		Developers who insist that tools and techniques are personal rather than a group decision generally get talked about unkindly. We are all in this together and you have to support things you don’t even use. That’s the facts on the ground, and more importantly, that’s the job.
	▲	IshKebab 4 days ago \| parent \| prev [-]
		> Should users that refuse to learn the tool really be the target? Maybe not, but that's not the only group of people that are affected. It also affects beginners and people that don't want to exhaustively read the manual. Should they be the target? Obviously yes.