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

From: nUxi Codes <code@nuxi.name>
Date: Aug 20, 2011, 04:19 UTC
Message-ID: <CAD7xuUmtndhbWz7H0uQJ3gkbqurBGOsK8ATx6og9VifS6kc9fw@mail.gmail.com>

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.