From: Jonathan Nieder <jrnieder@gmail.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: git@vger.kernel.org, fbriere@fbriere.net, drizzd@aon.at
Subject: Re: [long] worktree setup cases
Date: Wed, 20 Oct 2010 22:30:42 -0500 [thread overview]
Message-ID: <20101021033042.GA1891@burratino> (raw)
In-Reply-To: <AANLkTimzfxJFz2FRVCJ7b4+icXMxpQGNo0WGm_BXzXNy@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On Thu, Oct 21, 2010 at 2:07 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> - otherwise, if original cwd was under repository,
[...]
>> GIT_WORK_TREE defaults to unset.
>
> What do you mean by "under repository"? If the repo is /tmp/git/.git,
> then cwd is at /tmp/git/.git?
I meant if the original cwd lies within the repository.
Example:
repo /tmp/git/.git
starting cwd /tmp/git/.git/objects/pack
>> D. User-supplied relative paths.
>>
>> - path in .git file is relative to containing directory
>> - path in GIT_DIR is relative to original cwd
>> - paths in GIT_WORK_TREE and core.worktree are relative to
>> $GIT_DIR
>
> I think $GIT_WORK_TREE is relative to original cwd.
git.txt is confusing, then. Actually it has some other insights:
--work-tree=<path>
Set the path to the working tree. The value
will not be used in combination with
repositories found automatically in a .git
directory (i.e. $GIT_DIR is not set).
So GIT_WORK_TREE should be discarded or warned about when GIT_DIR is
not set. (?)
This can also be controlled by setting the
GIT_WORK_TREE environment variable and the
core.worktree configuration variable. It can be
an absolute path or relative path to the
directory specified by --git-dir or GIT_DIR.
This is where I got the impression about relative paths.
Note: If --git-dir or GIT_DIR are specified but
none of --work-tree, GIT_WORK_TREE and
core.worktree is specified, the current working
directory is regarded as the top directory of
your working tree.
Nice to see this case is documented.
> Yes, core.worktree
> should be relative to $GIT_DIR.
Speaking of which, it is not clear to me that core.worktree should
fall under the forbidden case discussed above. If it does, what is
the point of making it configurable?
> Yes.
Thanks for checking.
Jonathan
next prev parent reply other threads:[~2010-10-21 3:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-20 8:59 [long] worktree setup cases Nguyen Thai Ngoc Duy
2010-10-20 19:07 ` Jonathan Nieder
2010-10-20 19:18 ` Jonathan Nieder
2010-10-21 1:46 ` Nguyen Thai Ngoc Duy
2010-10-21 3:30 ` Jonathan Nieder [this message]
2010-10-21 12:50 ` Nguyen Thai Ngoc Duy
2010-10-21 16:01 ` Jonathan Nieder
2010-10-23 10:12 ` Nguyen Thai Ngoc Duy
2010-10-21 18:51 ` Enrico Weigelt
2010-10-22 0:34 ` Nguyen Thai Ngoc Duy
2010-10-22 5:00 ` Enrico Weigelt
2010-10-22 5:28 ` .git file (Re: [long] worktree setup cases) Jonathan Nieder
2010-10-22 5:36 ` [long] worktree setup cases Nguyen Thai Ngoc Duy
2010-10-20 21:00 ` Junio C Hamano
2010-10-21 2:23 ` Nguyen Thai Ngoc Duy
2010-10-21 19:01 ` Enrico Weigelt
2010-10-21 23:06 ` Junio C Hamano
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=20101021033042.GA1891@burratino \
--to=jrnieder@gmail.com \
--cc=drizzd@aon.at \
--cc=fbriere@fbriere.net \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).