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

When passing objects to the `git log`, by just naming them or using the `--objects` option, relative paths are evaluated using the current working directory instead of the current working tree path.

Even the error message is clearly wrong.
    "unknown revision or path not in the working tree."

Example:

Given a repo at "~/path/to_repo" containing a file such as "README.md" ("~/path/to_repo/README.md")

~/path$ git --work-tree=~/path/to_repo log README.md fatal: ambiguous argument 'README.md': unknown revision or path not in the working tree.

As you can see here (https://github.com/robertodecurnex/git/blob/master/setup.c#L147) git is trying to `lstat` the path as it was given when it should validate the file existence within the work tree (perpending the work-tree before the file name).

Note: I now several workarounds for this, I'm not looking for a
solution to the specific problem but to discuss the implementation and
evaluate a change over the current behavior.

Regards, -- Roberto Decurnex

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.

Sorry, I left the --git-dir out of the example. I do set the --git-dir (and $GIT_DIR sometimes) too.

It gives the same results. That's why I feels like it shouldn't be working as it is.

In this specific case (log with object filter) the environment config is completely ignored.

On Mon, Sep 29, 2014 at 3:06 PM, Junio C Hamano <gitster@pobox.com> wrote:

Hi Roberto,

Roberto Eduardo Decurnex Gorosito wrote:

Why should they be relative to the worktree root? When you use relative paths within a worktree, they are not relative to the worktree root. For example, the following works within a clone of git.git:

	$ cd Documentation
	$ git log git.txt

You might be looking for 'git -C <directory>', which chdirs to the named directory so paths are relative to there.

Hope that helps, Jonathan

Ok. Yes, it 's kind of tricky. But the `-- <path>` does both things.

`-- <path>` looks for the relative path within the current directory but defaults to the work-tree root if your current directory does not belong to the repo.

About `git -C <dir>`, awesome feature, I love that, but it's not my point. (and I'm actually maintaining the ruby-git gem, supporting git

I really appreciate your feedback.

Regards, -- Roberto Decurnex

On Mon, Sep 29, 2014 at 5:56 PM, Jonathan Nieder <jrnieder@gmail.com> wrote: