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

> Roberto Eduardo Decurnex Gorosito <decurnex.roberto@gmail.com>
> 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.
>
>
>
>
>