All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Roberto Eduardo Decurnex Gorosito <decurnex.roberto@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: `git log relative_path_to_object` does not respect the --work-tree path
Date: Mon, 29 Sep 2014 11:06:22 -0700	[thread overview]
Message-ID: <xmqqy4t2ti75.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CABj5xzc0bVfyzR5PD5K3STSvdvWEOYeMkayB=GTfKbfij+G5Zw@mail.gmail.com> (Roberto Eduardo Decurnex Gorosito's message of "Mon, 29 Sep 2014 13:40:06 -0300")

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.

  reply	other threads:[~2014-09-29 18:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-29 16:40 `git log relative_path_to_object` does not respect the --work-tree path Roberto Eduardo Decurnex Gorosito
2014-09-29 18:06 ` Junio C Hamano [this message]
2014-09-29 18:11   ` Roberto Eduardo Decurnex Gorosito
2014-09-29 20:56 ` Jonathan Nieder
2014-09-30 12:42   ` Roberto Eduardo Decurnex Gorosito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqy4t2ti75.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=decurnex.roberto@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.