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

Roberto Eduardo Decurnex Gorosito <decurnex.roberto@gmail.com> writes:

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.