We have a project with many submodules. Since today I seem to break my local repos when I commit something in a submodule.
I get a warning first, and afterwards the .git folder is shown as a file instead of a directory. The biggest problem is, that even when I delete the submodule and reinitialize it, it's restored in the same broken state. The only way to get out of this situation is to delete the local repository and clone it again.
It gets broken when I:
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(develop -> origin)
λ git commit -m "SEC-165 - fix typo"
Now the .git folder no longer seems to be a folder
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(develop -> origin)
λ ls -all
total 89
drwxr-xr-x 1 BPR 1049089 0 Oct 26 12:15 ./
drwxr-xr-x 1 BPR 1049089 0 Oct 25 16:00 ../
-rw-r--r-- 1 BPR 1049089 55 Oct 26 12:15 .git
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(develop -> origin)
λ git status
warning: core.bare and core.worktree do not make sense
fatal: unable to set up work tree using invalid config
Deleting the submodule from disk and reinitialing it results in the same broken situation
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(develop -> origin)
λ rm -rf *
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(develop -> origin)
λ cd ..
C:\dev\iai.common.devices.exhaust\Common(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git submodule update --init --recursive
warning: core.bare and core.worktree do not make sense
fatal: unable to set up work tree using invalid config
fatal: Unable to checkout '159486a04efd86eceaad5e3adb74263b0ddc5d7e' in submodule path 'BuildEnvironment'
I never seen this weird behavior before, and remain clueless of how to fix it. Anybody and help / ideas?
update
I am not sure how git deals with submodules, but it seems that the .git item in a submodule simply not is a directory (??). So not sure if that has anything to do with the problem at hand. I really hope somebody can shed a light on this.
A full reproduction scenario, I didn't leave any action out:
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(HEAD detached at 159486a)
λ git status
HEAD detached at 159486a
nothing to commit, working tree clean
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(HEAD detached at 159486a)
λ git checkout feature/SEC-165-software-update-should-contains-plc-updates
Switched to a new branch 'feature/SEC-165-software-update-should-contains-plc-updates'
branch 'feature/SEC-165-software-update-should-contains-plc-updates' set up to track 'origin/feature/SEC-165-software-update-should-contains-plc-
updates'.
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ code .
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git add .
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git commit -m "fix typo"
warning: core.bare and core.worktree do not make sense
[feature/SEC-165-software-update-should-contains-plc-updates a3b1440] SEC-165 - fix typo
1 file changed, 1 insertion( ), 1 deletion(-)
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git status
warning: core.bare and core.worktree do not make sense
fatal: unable to set up work tree using invalid config
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
Update 2
Found something here.
git -c core.bare=false config --unset core.bare
That restore the broken situation, which at least saves me the trouble of cloning the entire repo again. It does not solve the root cause though. A new commit will destroy stuff again...
Below the actions for the workaround.
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git status
warning: core.bare and core.worktree do not make sense
fatal: unable to set up work tree using invalid config
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git -c core.bare=false config --unset core.bare
warning: core.bare and core.worktree do not make sense
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git status
On branch feature/SEC-165-software-update-should-contains-plc-updates
Your branch is up to date with 'origin/feature/SEC-165-software-update-should-contains-plc-updates'.
nothing to commit, working tree clean
Breaking things reproduces again with the known sequence
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ touch bla
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git add . && git commit
warning: core.bare and core.worktree do not make sense
[feature/SEC-165-software-update-should-contains-plc-updates d053a92] SEC-165 - bla
1 file changed, 0 insertions( ), 0 deletions(-)
create mode 100644 bla
C:\dev\iai.common.devices.exhaust\Common\BuildEnvironment(feature/SEC-165-software-update-should-contains-plc-updates -> origin)
λ git status
warning: core.bare and core.worktree do not make sense
fatal: unable to set up work tree using invalid config
What the hell is going on here. Why is git doing this? What can I have done what causes this insanely annoying behavior?
CodePudding user response：
git config --unset core.bare
in that submodule's work tree should do it.
When git submodule update clones a repo for you it hoists it out of the submodule work tree and leaves a breadcrumb .git file pointing to the (arbitrary) nook in the main repo where it set up the real clone. It does this because, without submodules, anything other than the repo itself in a work tree can be casually rm -rfed and restored to its pristine state by checkout/restore. Hoisting the submodule clone out of its work tree preserves that ability.
How exactly core.bare got set is an open question‚ but there's reasonable hope it was some sort of fatfinger and won't happen again.
CodePudding user response：
Problem solved...
We have very fancy git hooks, which are capable of updating themselves.
There seems to be a bug in these scripts when it comes to git submodules. For now I just commented out the update part in the git hook, and then everything works like it's supposed to again.