On Wed, Apr 12, 2017 at 3:41 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > >>> I think this is much more than just .mailmap, though. For instance, I >>> have noticed a similar problem with .gitattributes: >> >> Urgh. assuming that we should not read .gitattributes if there's no >> worktree to read from (similar to the "defaults to .git" situation), >> how about >> >> - if mailmap stuff is requested, setup worktree, or die trying >> - if worktree is detected, but setup code does not jump to it, do it >> - if no worktree is detected, tell git-log to stop reading .gitattributes > > My gut reaction is that we are doing something wrong once we start > saying "if mailmap stuff is requested". This is not about .mailmap > but is about how sanely the paths relative to the root of the > working tree (which includes a path in the index, or comparing > $commit:$path with $path in the working tree) can be named by any > subcommand of Git. I probably should phrased that as "if any worktree stuff is requested". I was under an impression that you need to pass a command line option to use mailmap, but I dind't check the code > 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. > Perhaps we want a new bit GOTO_WORK_TREE_ROOT that is orthogonal to > NEED_WORK_TREE to tell the codepath that calls cmd_foo() to always > move to the root of the working tree (if there is one), regaredless > of the behaviour f3bb8b4b84 documents. I have a strong suspicion > that we didn't _care_ about a silly use case where GIT_WORK_TREE is > specified and the command is started from somewhere completely > unrelated to that location, and the users with such a silly use case > didn't care either what Git does to the files in the working tree, > i.e. what you quoted in your previous message > > "11. When user's cwd is outside worktree, cwd remains unchanged, > prefix is NULL." > > This behavior probably started long before my topic though, mine was > more of documentation, making worktree detection more consistent. It's > > was not describing the design, but just describing whatever random > thing the code happened to be doing. I never said otherwise :) The only thing I was worried was how long it had behaved that way, long enough that scripts started to depend on it? If we can get rid of special cases in setup code, I will be the first one to be happier. -- Duy