Junio C Hamano <gitster@xxxxxxxxx> writes: > Having said that, thanks for a nice summary. > ... > >> 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? I was re-reading this thread, and changed my mind; I think we should have this series to avoid unnecessary regression, with or without clarifying (5), before 1.7.4 final. Even if some scripts you had trouble with started using GIT_WORK_TREE without specifying GIT_DIR because they misunderstood what these are designed to do, as long as the combination has been working consistently with the expectation of these scripts, ans as long as we can keep the same behaviour, I don't see a reason to change it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html