The shell syntax "export X=Y A=B" is not understood by all shells.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Finishing touches to the new test script.

* dg/submodule-in-dismembered-working-tree:
  t7409: make sure submodule is initialized and updated in more detail

The earlier test did not even make sure that the correct commit is
checked out in the submodule directory.  Inspect the result in a bit
more detail.

Signed-off-by: Daniel Graña <dangra@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

The combination of GIT_DIR and GIT_WORK_TREE can be used to manage
files in one directory hierarchy while keeping the repository that
keeps track of them outside the directory hierarchy.  For example:

    git init --bare /path/to/there
    alias dotfiles="GIT_DIR=/path/to/there GIT_WORK_TREE=/path/to/here git"

    cd /path/to/here
    dotfiles add file
    dotfiles commit -a -m "add /path/to/here/file"
    ...

lets you manage files under /path/to/here/ in the repository located
at /path/to/there.

git-submodule however fails to add submodules, as it is confused by
GIT_DIR and GIT_WORK_TREE environment variables when it tries to
work in the submodule, like so:

    dotfiles submodule add http://path.to/submodule
    fatal: working tree '/path/to/here' already exists.

Simply unsetting the environment where the command works on the
submodule is sufficient to fix this, as it has set things up so
that GIT_DIR and GIT_WORK_TREE do not even have to point at the
repository and the working tree of the submodule.

Signed-off-by: Daniel Graña <dangra@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>