On Mon, Apr 10, 2017 at 07:01:00PM +0700, Duy Nguyen wrote:
> > Similarly, if you replace "git add foo" with "git log", it still
> > should work in the above, i.e.
> >
> > $ export GIT_DIR=~/myproject/.git GIT_WORK_TREE=~/myproject
> > $ cd ~/myproject/../somewhere/else
> > $ git log
> >
> > If Git is not chdir(2)ing to ~/myproject before calling cmd_log()
> > in the above (again, this is my down week so I didn't and will not
> > check with the code myself), we may want to call that a bug and fix
> > it, so that you do not have to do anything special to get to the
> > path of ".mailmap" that is at the top-level.
>
> The behavior is "documented" in t1510 since f3bb8b4b84 (Merge branch
> 'nd/setup' - 2010-12-28)
>
> "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
> the same case with defining GIT_DIR without GIT_WORK_TREE, I think:
> scripts started to depend on a behavior that we did not clearly
> define, by the time we knew what we wanted and we kept the old
> behavior forever.
>
> I think it's just safer to go with Johannes' suggestion.
>
> An alternative is, when you have found out you need to read .mailmap,
> you call setup_work_tree() then, which prepares the worktree for you
> (including moving back to cwd) or dies if worktree does not exist, or
> no-op if worktree has already been asked by somebody. Many commands do
> lazy worktree initialization this way.
I think this is much more than just .mailmap, though. For instance, I
have noticed a similar problem with .gitattributes:
# set up a repo with an attribute
git init repo
(
cd repo &&
echo content >file &&
echo "file diff=sed" >.gitattributes &&
git add . &&
git commit -m foo &&
git config diff.sed.textconv 'sed s/^/foo:/'
)
If I run:
(cd repo && git log -p)
the diff for "file" shows:
+foo:content
as expected. But:
GIT_WORK_TREE=$PWD/repo GIT_DIR=$PWD/repo/.git git log -p
doesn't (while writing this I also noticed that "git log -p file"
doesn't work because of the DWIM lookup. That one is more debatable, but
I still think it makes more sense to move to $GIT_WORK_TREE).
-Peff