Re: [long] worktree setup cases

On Thu, Oct 21, 2010 at 11:01 PM, Jonathan Nieder [off-list ref] wrote:

Nguyen Thai Ngoc Duy wrote:

quoted

On Thu, Oct 21, 2010 at 10:30 AM, Jonathan Nieder [off-list ref] wrote:

quoted

quoted

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?

I was not the one who introduced core.worktree, so I can't really
tell. Maybe less keystrokes?

Yeah, it seems you're totally right. :(

Actually I have my part in this mess too: f5e025a (Documentation:
always respect core.worktree if set - 2009-12-29). I probably just
updated the document according to the code. It matches what Enrico
expects (i.e after .git discovery, worktree defaults is "../", if
core.worktree exists, follow it instead). Going back to the first
commit that introduced separate worktree, 892c41b (introduce
GIT_WORK_TREE to specify the work tree - 2007-06-06), core.worktree is
no different than --work-tree.

So what should it behave? Either revert f5e025a and update the code to
disregard/warn core.worktree if GIT_DIR/--work-tree is unset, or keep
the current behavior, i.e. core.worktree is different from
--work-tree/GIT_WORK_TREE.

The cleanup commit, e90fdc3 (Clean up work-tree handling -
2007-08-01), also gives something interesting regarding bare repo:
"--work-tree=bla overrides GIT_WORK_TREE, _which overrides core.bare =
true_, which overrides core.worktree, which overrides GIT_DIR/.. when
GIT_DIR ends in /.git, which overrides the directory in which .git/
was found.". I don't like this overriding chain, which is why I
proposed to die() if core.bare is set and worktree is explicitly
specified.
-- 
Duy