0

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://user@bitbucket.xxx.com/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?

JorgeeFG
  • 5,651
  • 12
  • 59
  • 92

1 Answers1

2

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

torek
  • 448,244
  • 59
  • 642
  • 775
  • 1
    Specifically, it looks like someone didn't fix a conflict properly, presumably during a merge or rebase operation. The `<<<` is quite telling. Look at git blame to see who did it. – Mad Physicist Aug 15 '18 at 22:03
  • @MadPhysicist But I don't understand why this error pops up when I try to switch to the int branch, and the file gets changed only after I do that. Because in master and int, the file is well formed (seen in Bitbucket web). – JorgeeFG Aug 15 '18 at 23:11
  • @MadPhysicist never mind I saw that it is in fact broken in int – JorgeeFG Aug 15 '18 at 23:13
  • The `.gitmodules` file is a file. As such, it's in *every* commit (well, every commit that has the file—switching to a commit that does *not* have the file, if there are any such, will *remove* the file from your work-tree). The copy in the commit at the current tip of `master` is well-formed. The copy in the commit at the current tip of `int` is malformed. Just like every committed file, every commit has a copy, but not all copies are the same! – torek Aug 15 '18 at 23:13
  • Now, how do I fix it in int if I cannot switch to it to make a `git checkout master .gitmodules` to bring the good one? PS: I was just questioning myself why there were new files after the failed attempt to switch branches, like if I added them. Seems that the repo gets into a broken state after that failed attempt and does not recover. – JorgeeFG Aug 15 '18 at 23:14
  • After `git checkout int`, you should be on the correct commit and branch in the superproject. The *submodule* may be incorrect, but you can fix the `.gitmodules` file itself, and `git add` the result. You can then run `git submodule update` to update the submodule (if needed), run any appropriate tests, and commit to the `int` branch. Note that you can just edit `.gitmodules` in an editor, the way you would edit any file. – torek Aug 15 '18 at 23:17
  • I've just tested it, it remains in branch master after throwing the error. – JorgeeFG Aug 15 '18 at 23:18
  • Hm, that's obnoxious. How about `git checkout --no-recurse-submodules`? (If that fails there's also `git checkout -f` but that is rather more drastic.) – torek Aug 15 '18 at 23:19
  • Same error. Also I checked in Centos and the output is Version 2.4.4 which is strange, as it is greater than mine in Windows (mine is latest acording to the git page). PS: I fixed it in Centos and pushed the commit, now it works in my local – JorgeeFG Aug 15 '18 at 23:22
  • Searching the source code, I find that `submodule.recurse` controls whether Git will automatically recurse into submodules. If you configure this to false, e.g., `git -c submodule.recurse=false checkout int`, that should also stop the problem—but `--no-recurse-submodules` should have done it as well, and if it doesn't, that seems like a bug. (Side note: 2.4.4 < 2.18, but it is good to see that some CentOS versions have upgraded to Git 2.x :-) ) – torek Aug 15 '18 at 23:30