From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, fbriere@fbriere.net, drizzd@aon.at,
575917@bugs.debian.org
Subject: Re: [long] worktree setup cases
Date: Thu, 21 Oct 2010 08:46:44 +0700 [thread overview]
Message-ID: <AANLkTimzfxJFz2FRVCJ7b4+icXMxpQGNo0WGm_BXzXNy@mail.gmail.com> (raw)
In-Reply-To: <20101020190709.GB10537@burratino>
On Thu, Oct 21, 2010 at 2:07 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> So there are 2^5 = 32 cases in total. Let's look at them one by
>> one.
>
> Thanks! To summarize (and make sure I understand correctly):
> anything not following the below rules is a bug, yes?
Let's see.
> A. Weird cases.
>
> - using a .git file is just like setting GIT_DIR;
Yes, except that GIT_DIR can be detected early when cwd has not been
moved. When .git is found a file, cwd could have been changed.
> B. Repository search.
>
> - if GIT_DIR was set explicitly, GIT_WORK_TREE defaults to
> "." (for legacy reasons).
Correct.
> - otherwise, if original cwd was under repository, it will not
> prompt a search for work tree, even if the repo happens
> to be named ".git" or core.bare is false. That is, in
> this case, 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?
> - otherwise, if original cwd was under a directory containing
> repository as ".git", GIT_WORK_TREE defaults to that
> directory (i.e., parent to .git dir).
Yes.
> - otherwise, there is no repository. GIT_DIR is unset,
> GIT_WORK_TREE defaults to unset.
- Otherwise, move up one dir and repeat?
> C. Working directory and prefix
>
> - if GIT_WORK_TREE is still unset after repository search,
> stay in the original cwd, prefix = NULL.
if GIT_WORK_TREE and core.worktree are still unset, we get a bare repo
here (or force it to be a bare repo), so yes, cwd should stay in
original cwd and prefix = NULL.
> - if original cwd is inside worktree, chdir to toplevel,
> prefix = path to original cwd.
Yes.
> - otherwise, stay in the original cwd, prefix = NULL.
I'm not really happy with this, which is why I wrote the
--cwd-to-worktree and --worktree-to-cwd patch. But this should be
enough for full-tree operations to work, so yes.
> 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. Yes, core.worktree
should be relative to $GIT_DIR.
> - paths passed to git commands are generally relative to
> original cwd
And filename output should also be relative to original cwd (except a
few special, like diff output).
> E. Internally used relative paths.
>
> - all paths are relative to current cwd.
Yes.
--
Duy
next prev parent reply other threads:[~2010-10-21 1:47 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 [this message]
2010-10-21 3:30 ` Jonathan Nieder
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=AANLkTimzfxJFz2FRVCJ7b4+icXMxpQGNo0WGm_BXzXNy@mail.gmail.com \
--to=pclouds@gmail.com \
--cc=575917@bugs.debian.org \
--cc=drizzd@aon.at \
--cc=fbriere@fbriere.net \
--cc=git@vger.kernel.org \
--cc=jrnieder@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).