I have a repository with a submodule configured.
In .gitmodules, the "update = merge" option is set for the submodule.
I am cloning the repo down from, for example, GitHub.
After cloning the parent repo down, I run a:
git submodule init
git submodule update
With git 1.7.2.5 from Squeeze, the resulting submodule repo is
unexpectedly bare. The contents aren't there. 1.7.2.5 is printing:
... (git clone) ...
user@oldhost:~/parentdir$ git submodule init
Submodule 'mysubmodule' (git://github.com/user/submodule.git)
registered for path 'submoduledir'
user@oldhost:~/parentdir$ git submodule update
Cloning into submoduledir...
remote: Counting ....(skipping the obvious).... deltas: 100%
(###/###), done.
Already up-to-date.
Submodule path 'submodule': merged in
'450e1a4ca6705c193d92b34e247fb63d32416c81'
user@oldhost:~/parentdir$ ls submodule
.git
user@oldhost:~/parentdir$
With git 1.7.6 built on FreeBSD, the contents of the submodule are
there. It is not bare.
... (Same) ...
Submodule path 'bundle/pathogen': checked out
'450e1a4ca6705c193d92b34e247fb63d32416c81'
user@newhost:~/parentdir$ ls submodule
.git Stuff Things
.gitignore ...etc...
user@newhost:~/parentdir$
Why the difference? Was this fixed intentionally?
If so, why hasn't Debian backported the fix? It breaks a very common
way of setting things up.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html