Re: [PATCH 3/3] setup: always honor GIT_WORK_TREE and core.worktree

Jonathan Nieder [off-list ref] writes:

Maaartin wrote:

quoted

On 11-01-19 13:42, Jonathan Nieder wrote:

quoted

quoted

Unfortunately the existence of GIT_WORK_TREE makes it tempting to
use without setting GIT_DIR.

Maybe I'm asking nonsense, but why should I always use both?

That is, why do we want to discourage setting the work tree without
GIT_DIR in the first place?

I read that one quite differently.  Maaartin was always at the root level
and did not need GIT_WORK_TREE, and in such a case there is no need to use
both.  Only GIT_DIR is needed.

    This is a tangent, because I just said what Maaartin said is
    irrelevant to the question "Why do I have to set GIT_DIR when I want
    to set GIT_WORK_TREE?", which is what you are discussing, but I
    suspect Maaartin was not getting the correct output from diff commands
    by having two sets of "working tree" looking files, chdir'ing to their
    root level and having a single GIT_DIR, and was not noticing it.  It
    should _not_ work: think "index".

The answer to your question might be your question itself, though.

Having said that, thanks for a nice summary.

1. Previously there was some confusion about what path the worktree
   is relative to.  Now setup_explicit_git_dir makes it clear:
   + GIT_WORK_TREE and --work-tree are relative to the original cwd;
   + the "[core] worktree" setting is relative to the gitdir.

Good.  I earlier said that relative GIT_WORK_TREE does not make much
sense, but I wasn't (and I am not) opposed to the above definition.  It is
just that

	GIT_DIR=/some/where; export GIT_DIR
        cd /some/other/place
        GIT_WORK_TREE=. git reset --hard
	cd onelevel
	edit edit edit
        GIT_WORK_TREE=.. git add file
        cd twolevels
        edit edit edit
        GIT_WORK_TREE=../.. git add file
	...

would be a much more cumbersome thing to do compared to:

	GIT_WORK_TREE=/some/other/place; export GIT_WORK_TREE
        cd $(GIT_WORK_TREE)
        git reset --hard
	cd onelevel
	edit edit edit
	git add file
        cd twolevels
        edit edit edit
        git add file
	...

5. The interaction with core.bare and implicit bareness are not
   obvious.  Clearly core.bare should conflict with core.worktree,
   but can GIT_WORK_TREE override that?  Maybe
   check_repository_format_gently is the right place for this check
   (rather than the setup procedure).

IIRC, we on purpose added support to allow GIT_WORK_TREE to tentatively
lift bareness of a repository so that people can

	cd /var/tmp
        GIT_WORK_TREE=. git --git-dir=/srv/git/jgit.git checkout -f

to get a snapshot easily.

(1) and (2) have been resolved by your work (nice!), (3) seems like
a case of "don't do that, then", and (4) out to error out in
setup_nongit (though my patch doesn't take care of that).  Given an
answer to (5) we could wholeheartedly and consistently support
worktree with implicit gitdir, as a new feature.

As long as we really can support it _consistently_, I wouldn't see a big
problem in resurrecting the historical accident as a feature.  You earlier
said gitolite also misuses the interface, but does the usage pattern it
has the same as the one in the debian script you had trouble with, and do
they expect the same behaviour?