>From Damien Robert, Thu 27 Feb 2020 at 11:43:30 (+0100) : > And looking at setup.c:760 it appears that `set_git_dir` (which set up among > other things the GIT_DIR env) is called because we are in a worktree. > > More precisely: we have discovered a git dir (a git file), so we call > setup_discovered_git_dir, which itself calls setup_explicit_git_dir because > we are in a work tree environment. And set_up_explicit_git_dir calls > set_git_dir. > > So I don't know what's the proper way to fix this. Keep track when we add > ourselves the GIT_DIR rather than when it is already provided and remove it > before executing a shell alias? Don't run the full configuration setup when > we are executing a shell alias anyway? Sorry about the spam. Thinking about it some more, this has nothing to do with submodules or worktrees, but about how we expect shell aliases to work. In Documentation/config/alias, it is documented that the alias will run a the top level and GIT_PREFIX will be set. In git.c#handle_alias, it is explicitly stated that shell alias call setup_git_directory_gently because: /* Aliases expect GIT_PREFIX, GIT_DIR etc to be set */ So one might argue that the behaviour I observed is not a bug, but it is still surprising for me (as a user), and maybe this could be stated more clearly in the docs? Furthermore there is a question of consistency. GIT_DIR will not always be set before running a shell alias. Looking at `setup_discovered_git_dir`, it will be set if we are in a bare dir, or core.worktree / WORK_TREE is set, or if we have a gitfile. The annoying side effect is that I cannot use as an alias a command that iterate over submodules and run git commands inside them, because in this alias GIT_DIR will be set sometimes, and sometimes not (a quick fix would be to unset GIT_DIR in my alias). So what would be the best way to handle this? Thanks, Damien
