Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> I agree, but this case is special. The test asserts that nobody
> added, modified or removed *anything* inside the .git directory.
> The reason for problem we are seeing here is that I have to
> remove the core.worktree setting when moving the git directory
> from .git/modules into the submodule work tree.
Hmph. Comparing the files with core.worktree removed sounds like a
workaround that knows too much about the implementation detail of
what is being tested. I am just wondering if core.worktree will
stay forever be the only thing that is special, or there may come
other things (perhaps as a fallout of integrating things like Duy's
multiple-worktree stuff).
But perhaps we cannot do better than this.
> Could you please test the following? It should avoid this kind
> of problem by removing the core.worktree setting temporarily
> from the original config in .git/modules instead of adding it
> temporarily to .git/config:
> -----------------------8<-----------------------
> diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
> index 3584755..98c86e3 100755
> --- a/t/lib-submodule-update.sh
> +++ b/t/lib-submodule-update.sh
> @@ -143,18 +143,18 @@ replace_gitfile_with_git_dir () {
> }
>
> # Test that the .git directory in the submodule is unchanged (except for the
> -# core.worktree setting, which we temporarily restore). Call this function
> +# core.worktree setting, which we temporarily remove). Call this function
> # before test_submodule_content as the latter might write the index file
> # leading to false positive index differences.
> test_git_directory_is_unchanged () {
> (
> - cd "$1" &&
> - git config core.worktree "../../../$1"
> + cd ".git/modules/$1" &&
> + git config --unset core.worktree
> ) &&
> diff -r ".git/modules/$1" "$1/.git" &&
> (
> - cd "$1" &&
> - GIT_WORK_TREE=. git config --unset core.worktree
> + cd ".git/modules/$1" &&
> + git config core.worktree "../../../$1"
> )
> }
--
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