Roberto Eduardo Decurnex Gorosito <[email protected]>
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
