Compiler specs fail if git is configured with a different defaultBranch

[yxhuvud]

Bug Report

How to reproduce:

Have a .gitconfig that includes

[init]
	defaultBranch = main

In checked out crystal repo, run the compiler specs:

make clean
make
make compiler_spec

This results in 3 faileures:

crystal spec spec/compiler/crystal/tools/doc/project_info_spec.cr:93 # Crystal::Doc::ProjectInfo #fill_with_defaults with shard.yml git non-tagged commit
crystal spec spec/compiler/crystal/tools/doc/project_info_spec.cr:105 # Crystal::Doc::ProjectInfo #fill_with_defaults with shard.yml git non-tagged commit dirty
crystal spec spec/compiler/crystal/tools/doc/project_info_spec.cr:142 # Crystal::Doc::ProjectInfo .find_git_version

All three are failing due to master being hardcoded.

• Include Crystal compiler version (crystal -v) and OS. If possible, try to see if the bug still reproduces on master.

I had 1.3.1 checked out when I ran into the issue.

[yxhuvud]

Do we have any version requirement on git? It turns out defaultBranch was added in 2.28.0. Would it be ok to add --initial-branch=master to the git initialization in those specs? I believe (but havn't verified) that option was also added then.

[HertzDevil]

Should we do the opposite and query for init.defaultbranch in the specs?

[yxhuvud]

Right, that is probably safer. I was initially under the impression that fetching unknown keys gave an error message, but that is not the case.

[straight-shoota]

I would rather prefer to eliminate influence of local configuration from the spec code instead of adapting to it. We're better off using the same well defined behaviour everyhwere.

That means adding --initial-branch=master to git init.

[lbguilherme]

Another approach could be to ignore global and system configs by setting the env variables GIT_CONFIG_GLOBAL and GIT_CONFIG_SYSTEM to point to empty files.

Ref: https://git-scm.com/docs/git-config#Documentation/git-config.txt-GITCONFIGGLOBAL

[straight-shoota]

That might even be better because other settings might influence git behaviour as well 👍
It only works as long as git doesn't change the default, though.

[yxhuvud]

@straight-shoota Adding --initial-branch=master means adding a requirement on git 2.28.0 to run the test suite. Is that old enough that it is ok?

[yxhuvud]

@lbguilherme perhaps even GIT_CONFIG_NOSYSTEM could be pretty nice. Then there wouldn't be any need to set up any temporary files.

[lbguilherme]

Unfortunately GIT_CONFIG_NOSYSTEM doesn't stop git from using the global config at your home, only the system-wide one.

[yxhuvud]

An alternative could be to simply checkout some directory with
git checkout -b master
Would add an extra line but would perhaps be a bit more explicit and clearer, while avoiding the version issues?

[straight-shoota]

We should go with git checkout -b master after git init in the affected specs.
I suppose it's even an improvement for reading the spec code because it explicitly defines the value.

And it's a smaller diff and less introduced complexity than the current proposal in #11754