Daniel Graña <dangra@xxxxxxxxx> writes: > A common way to track dotfiles with git is using GIT_DIR and > GIT_WORK_TREE to move repository out of ~/.git with something like: > > git init --bare ~/.dotfiles > alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git" > > dotfiles add ~/.bashrc > dotfiles commit -a -m "add my bashrc" > ... > > but git-submodule complains when trying to add submodules: > > dotfiles submodule add http://path.to/submodule > fatal: working tree '/home/user' already exists. > > git --git-dir ~/.dotfiles submodule add http://path.to/submodule > fatal: /usr/lib/git-core/git-submodule cannot be used without a > working tree. > > Signed-off-by: Daniel Graña <dangra@xxxxxxxxx> > --- I think this is in line with what we discussed earlier on list when the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up the last time. Jens? > git-submodule.sh | 7 +++- > t/t7409-submodule-detached-worktree.sh | 61 ++++++++++++++++++++++++++++++++ > 2 files changed, 66 insertions(+), 2 deletions(-) > create mode 100755 t/t7409-submodule-detached-worktree.sh > > diff --git a/git-submodule.sh b/git-submodule.sh > index 5629d87..88ee4ea 100755 > --- a/git-submodule.sh > +++ b/git-submodule.sh > @@ -181,8 +181,11 @@ module_clone() > rm -f "$gitdir/index" > else > mkdir -p "$gitdir_base" > - git clone $quiet -n ${reference:+"$reference"} \ > - --separate-git-dir "$gitdir" "$url" "$sm_path" || > + ( > + clear_local_git_env > + git clone $quiet -n ${reference:+"$reference"} \ > + --separate-git-dir "$gitdir" "$url" "$sm_path" > + ) || > die "$(eval_gettext "Clone of '\$url' into submodule path > '\$sm_path' failed")" Line-wrapped broken patch? > fi > > diff --git a/t/t7409-submodule-detached-worktree.sh > b/t/t7409-submodule-detached-worktree.sh > new file mode 100755 > index 0000000..db75642 > --- /dev/null > +++ b/t/t7409-submodule-detached-worktree.sh > @@ -0,0 +1,61 @@ > +#!/bin/sh > +# > +# Copyright (c) 2012 Daniel Graña > +# > + > +test_description='Test submodules on detached working tree > + > +This test verifies that "git submodule" initialization, update and > addition works Line-wrapped broken patch? > +on detahced working trees > +' > + > +TEST_NO_CREATE_REPO=1 > +. ./test-lib.sh > + > +test_expect_success 'submodule on detached working tree' ' > + git init --bare remote && > + test_create_repo bundle1 && > + (cd bundle1 && test_commit "shoot") && > + mkdir home && > + ( > + cd home && > + export GIT_WORK_TREE="$(pwd)" GIT_DIR="$(pwd)/.dotfiles" && > + git clone --bare ../remote .dotfiles && > + git submodule add ../bundle1 .vim/bundle/sogood && > + test_commit "sogood" && > + git push origin master > + ) && Don't you want to verify not just commands succeed, but leave a reasonable result, e.g. by running "git rev-parse HEAD" in "remote" and comparing the output with "git rev-parse HEAD" in .dotfiles, or something? > + mkdir home2 && > + ( > + cd home2 && > + export GIT_WORK_TREE="$(pwd)" GIT_DIR="$(pwd)/.dotfiles" && > + git clone --bare ../remote .dotfiles && > + git submodule update --init Likewise. What state, other than "submodule update --init" does not barf, do you expect to see? > + ) > +' > + > +test_expect_success 'submodule on detached working pointed by core.worktree' ' > + mkdir home3 && > + ( > + cd home3 && > + export GIT_DIR="$(pwd)/.dotfiles" && > + git clone --bare ../remote "$GIT_DIR" && > + git config core.bare false && > + git config core.worktree .. && > + git submodule add ../bundle1 .vim/bundle/dupe && > + test_commit "dupe" && > + git push origin master Likewise. > + ) && > + ( > + cd home && > + export GIT_DIR="$(pwd)/.dotfiles" && > + git config core.bare false && > + git config core.worktree .. && > + git pull && > + git submodule update && > + git submodule status && > + test -d .vim/bundle/dupe Likewise. Is there something you want to verify in the branches in the submodule and its working tree, other than the existence of that directory? > + ) > +' > + > +test_done -- 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