On Wed, Apr 12, 2017 at 06:13:49PM +0700, Duy Nguyen wrote: > > Can't we model this after how setup_git_directory_gently() gives the > > subcommands a choice? While the majority of subcommands do not call > > the _gently() variant and die when we are not in a repository, the > > rest do use it and continue after learning that they are outside a > > repository. > > It may work, but we need to be careful because paths as command line > arguments will not be relative to cwd anymore. If some code assumes > cwd unchanged, they're in trouble. I guess they're in trouble either > way because of the "sometimes chdir, sometimes not" current behavior. Exactly. The code itself must respect "prefix", and if it doesn't, it's broken. So I don't think a code switch makes any sense here. It's not the code which needs to care, it's the user who might be relying on the externally visible behavior. I can't think of a case where the existing behavior actually makes sense for the user, though. They've provided a $GIT_WORK_TREE, but somehow want their out-of-worktree relative paths to still work? What are they using the paths for? Surely: cd /out-of-tree echo content >foo GIT_DIR=/repo/.git GIT_WORK_TREE=/repo git add foo shouldn't work? Likewise reading .mailmap and .gitattributes from /out-of-tree is simply a bug. I dunno. Maybe I am missing some subtle case, but it's not clear to me what the user would be trying to do by having git stay in the original directory. -Peff