'git submodule update' w/ .gitmodules 'update=merge' behaves differently on git 1.7.6 vs 1.7.2.5

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.

On 20 August 2011 00:19, nUxi Codes [off-list ref] wrote:

Was this fixed intentionally?

Apparently, it was-
http://permalink.gmane.org/gmane.comp.version-control.git/169364 .

If so, why hasn't Debian backported the fix [to stable]?  It breaks...

This question remains.