Subject: Re: `git log relative_path_to_object` does not respect the --work-tree path

From: Junio C Hamano <[email-masked]>
Date: Mon, 29 Sep 2014 11:06:22 -0700

Roberto Eduardo Decurnex Gorosito <[email-masked]>
writes:

> ~/path$ git --work-tree=~/path/to_repo log README.md

This does not seem to specify GIT_DIR explicitly (either with the
$GIT_DIR environment variable or the --git-dir option), so I would
assume that you are sitting in a directory that has ".git/"
subdirectory or a subdirectory of such a directory, but that ".git/"
is not a real repository that controls the working tree you have at
the ~/path/to_repo directory.

The --work-tree option and $GIT_WORK_TREE environment were primarily
invented to solve this problem:

    When a user gives $GIT_DIR or --git-dir to disable the
    repository discovery (i.e. trying to see if the current
    directory has ".git/" that looks like a repository, and if not
    try the parent directory until we find one), traditionally we
    assumed that the current directory is the top-level of the
    corresponding working tree.  This makes it cumbersome to work
    inside a subdirectory, and by allowing $GIT_WORK_TREE or
    --work-tree to specify the top-level of the working tree,
    working from a subdirectory of a working tree becomes usable
    again.

That is why it does not mix very well with repository discovery
(i.e.  letting Git crawl upward from the current directory to find a
directory with ".git/").  It is unclear if the auto-discovered
".git" is the one to be be consulted for the "log" operation you
asked, or the other repository you have at ~/path/to_repo/.git (or
one of its parent directories, e.g. ~/path/.git).  I _think_ the
current implementation randomly chose to use the auto-discovered
one, but it may have been better to forbid and always require both
--git-dir and --work-tree to be given to avoid confusion.