Daniel Graña <[email protected]> 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 <[email protected]>
> ---
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
