CODEWITHSUNDEEP
git
JorgeeFG
JorgeeFG

Reputation: 5961

git 2.18 win64, strange error when checking out branch, only in my PC

It is an strange error, I'll paste the steps so you can understand better:

PS C:\Users\user\Proyectos\GRV\Repos> git clone https://[email protected]/scm/in004/site-code.git in004_code

Cloning into 'in004_code'...
remote: Counting objects: 4034, done.
remote: Compressing objects: 100% (3565/3565), done.
remote: Total 4034 (delta 366), reused 4010 (delta 358)
Receiving objects: 100% (4034/4034), 10.11 MiB | 280.00 KiB/s, done.
Resolving deltas: 100% (366/366), done.
Checking out files: 100% (3577/3577), done.
PS C:\Users\user\Proyectos\GRV\Repos> cd .\in004_code\
PS C:\Users\user\Proyectos\GRV\Repos\in004_code> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
PS C:\Users\user\Proyectos\GRV\Repos\in004_code> cat .\.gitmodules
[submodule "sites/default/files"]
        path = sites/default/files
        url = ../site-files.git
[submodule "profiles/hub"]
        path = profiles/hub
        url = ../../hub/hub-profile.git
        branch = 0.x
PS C:\Users\user\Proyectos\GRV\Repos\in004_code> git checkout int
fatal: bad config line 7 in file C:/Users/user/Proyectos/GRV/Repos/in004_code/.gitmodules
PS C:\Users\user\Proyectos\GRV\Repos\in004_code> cat .\.gitmodules
[submodule "sites/default/files"]
        path = sites/default/files
        url = ../site-files.git
[submodule "profiles/hub"]
        path = profiles/hub
        url = ../../hub/hub-profile.git
<<<<<<< HEAD
        branch = 0.x
=======
>>>>>>> 5580772... Initial commit qa
PS C:\Users\user\Proyectos\GRV\Repos\in004_code>

But this doesn't happen to a colleague neither in a centos server where I tested the same steps.

Any help?

Upvotes: 0

Views: 54

Answers (1)

torek
torek

Reputation: 488183

Minor edit / update: It looks like the particular control setting for seeing this error by default is recurse.submodules, which was introduced in Git 2.14. Versions of Git that predate 2.14 will ignore any recurse.submodules=true setting, while 2.14 and later will obey it. It also looks like there may be a bug with git checkout --no-recurse-submodules not clearing the flag at the right time. However, git -c recurse.submodules=false checkout ... should get past that. I'd argue that the failure itself—the exit with fatal: ... aborting the checkout—is a bug, too, but that's less clear.

The Git versions that come with many CentOS distributions are ancient, and fail to check for error cases. (You did not say which CentOS they are using, nor show their Git version, but see, e.g., How to install latest version of git on CentOS 7.x/6.x or the more recent Can't clone any repository using git. There is nothing wrong with being conservative about updating software, but there's conservative, and then there's CentOS...)

Your actual repository has an error in it: a .gitmodules file should always be well-formed, but the one in the tip of your int branch is not. Your Git is modern and immediately discovers the problem when you run git checkout int.

Their Git is ancient, so when you check out the int branch there, their Git quietly ignores the problem. The problem is still there, you just do not get a complaint. The problem needs to be fixed (by repairing the .gitmodules file and making a new commit on the int branch).

Upvotes: 2

Related Questions