• Jeff King's avatar
    setup: suppress implicit "." work-tree for bare repos · 2cd83d10
    Jeff King authored
    If an explicit GIT_DIR is given without a working tree, we
    implicitly assume that the current working directory should
    be used as the working tree. E.g.,:
      GIT_DIR=/some/repo.git git status
    would compare against the cwd.
    Unfortunately, we fool this rule for sub-invocations of git
    by setting GIT_DIR internally ourselves. For example:
      git init foo
      cd foo/.git
      git status ;# fails, as we expect
      git config alias.st status
      git status ;# does not fail, but should
    What happens is that we run setup_git_directory when doing
    alias lookup (since we need to see the config), set GIT_DIR
    as a result, and then leave GIT_WORK_TREE blank (because we
    do not have one). Then when we actually run the status
    command, we do setup_git_directory again, which sees our
    explicit GIT_DIR and uses the cwd as an implicit worktree.
    It's tempting to argue that we should be suppressing that
    second invocation of setup_git_directory, as it could use
    the values we already found in memory. However, the problem
    still exists for sub-processes (e.g., if "git status" were
    an external command).
    You can see another example with the "--bare" option, which
    sets GIT_DIR explicitly. For example:
      git init foo
      cd foo/.git
      git status ;# fails
      git --bare status ;# does NOT fail
    We need some way of telling sub-processes "even though
    GIT_DIR is set, do not use cwd as an implicit working tree".
    We could do it by putting a special token into
    GIT_WORK_TREE, but the obvious choice (an empty string) has
    some portability problems.
    Instead, we add a new boolean variable, GIT_IMPLICIT_WORK_TREE,
    which suppresses the use of cwd as a working tree when
    GIT_DIR is set. We trigger the new variable when we know we
    are in a bare setting.
    The variable is left intentionally undocumented, as this is
    an internal detail (for now, anyway). If somebody comes up
    with a good alternate use for it, and once we are confident
    we have shaken any bugs out of it, we can consider promoting
    it further.
    Signed-off-by: default avatarJeff King <peff@peff.net>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
environment.c 7.33 KB