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

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

[Roberto Eduardo Decurnex Gorosito]

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

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

[Junio C Hamano]

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.

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

[Roberto Eduardo Decurnex Gorosito]

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:
> 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.
>
>
>
>
>

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

[Jonathan Nieder]

Hi Roberto,

Roberto Eduardo Decurnex Gorosito wrote:

> 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.

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

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

[Roberto Eduardo Decurnex Gorosito]

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
>= 1.6 T_T)

I really appreciate your feedback.

Regards,
--
Roberto Decurnex

On Mon, Sep 29, 2014 at 5:56 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Roberto,
>
> Roberto Eduardo Decurnex Gorosito wrote:
>
>> 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.
>
> 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