git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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,
	575917@bugs.debian.org
Subject: Re: [long] worktree setup cases
Date: Wed, 20 Oct 2010 14:07:09 -0500	[thread overview]
Message-ID: <20101020190709.GB10537@burratino> (raw)
In-Reply-To: <20101020085859.GA13135@do>

Nguyen Thai Ngoc Duy wrote:

> 1. When .git is a file and contains a relative path, I assume it is
>    relative to .git file's parent directory.  read_gitfile_gently()
>    function will make the path absolute, but it depends on (maybe
>    wrong) cwd.

Yep.

> 2. Relative path is preferred over absolute path.

I'm tempted to say: let's use absolute paths where it's more
convenient.  They can be changed to relative paths as an afterthought
after the bugs are gone.

Relative paths have two big advantages over absolute paths,
which are avoiding path traversal overhead and allowing paths
longer than PATH_MAX.  Supporting the latter consistently
would presumably require using openat() and co, though.

> 3. core.worktree is overidden by GIT_WORK_TREE

Yeah.

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

A. Weird cases.

 - using a .git file is just like setting GIT_DIR;
 - setting core.worktree is just like setting GIT_WORK_TREE.

B. Repository search.

 - if GIT_DIR was set explicitly, GIT_WORK_TREE defaults to
   "." (for legacy reasons).

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

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

 - otherwise, there is no repository.  GIT_DIR is unset,
   GIT_WORK_TREE defaults to unset.

C. Working directory and prefix

 - if GIT_WORK_TREE is still unset after repository search,
   stay in the original cwd, prefix = NULL.

 - if original cwd is inside worktree, chdir to toplevel,
   prefix = path to original cwd.

 - otherwise, stay in the original cwd, prefix = NULL.

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
 - paths passed to git commands are generally relative to
   original cwd

E. Internally used relative paths.

 - all paths are relative to current cwd.

  reply	other threads:[~2010-10-20 19:10 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 [this message]
2010-10-20 19:18   ` Jonathan Nieder
2010-10-21  1:46   ` Nguyen Thai Ngoc Duy
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=20101020190709.GB10537@burratino \
    --to=jrnieder@gmail.com \
    --cc=575917@bugs.debian.org \
    --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).