Duy Nguyen <pclo...@gmail.com> 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.

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.  

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.

Reply via email to