Show 15 quoted lines
> We always ignore anything named .git, but we should also ignore the git
> directory if the user overrides it by setting $GIT_DIR
>
> Reported-By: Ingy döt Net <ingy@ingy.net>
> Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
> ---
> dir.c | 2 +-
> t/t7508-status.sh | 7 +++++++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/dir.c b/dir.c
> index 23b6de4..884b37d 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1198,7 +1198,7 @@ static enum path_treatment treat_path(struct dir_struct *dir,
The special case for ".git" is hardcoded in many places in git, including the line immediately above this diff hunk. So I figure that GIT_DIR is not meant to _rename_ the ".git" dir, but to point somewhere _outside_ the worktree (or somewhere within the .git dir).
If we want to support the rename case fully, I think there are a few more questions to answer (and a few more places to change), e.g.:
- What if GIT_DIR=.foo and someone upstream adds a ".foo" directory?
- Should it be possible to track ".git" as a normal file or directory if its not the GIT_DIR?
- What about other commands than status, e.g. does 'git clean -df' leave the GIT_DIR alone?
If we don't want to support this, though, I think it would be more approrpiate to issue a warning if GIT_DIR points to a worktree location.
Karsten Blees <karsten.blees@gmail.com>