Git.pm normalizes $GIT_DIR, was Re: git-send-email does not use conditional configuration

From: Jeff King <peff@peff.net>
Date: Sep 11, 2019, 18:05 UTC
Message-ID: <20190911180501.GA26087@sigill.intra.peff.net>
In-Reply-To: <d4717b7f-b7a4-208b-6b83-7993b6bd7886@dalamagkidis.info>

On Wed, Sep 11, 2019 at 06:58:26PM +0200, Konstantinos Dalamagkidis wrote:

Show 20 quoted lines

> I am using "includeIf.gitdir:/work". I tried to reproduce it at my home
> workstation where I have the exact same configuration, but in the beginning
> I couldn't. Then I realized, that at work the /work folder is actually a
> symlink to a different directory. When I did the same at home, I could
> reproduce the issue:
> 
> % pwd
> /work/repo
> % git send-email --dry-run -1 --to nobody | grep ^From
> From: Konstantinos Dalamagkidis <work-email@example.com>
> % cd ../repo-symlink
> % git send-email --dry-run -1 --to nobody | grep ^From
> From: Konstantinos Dalamagkidis <personal-email@example.com>
> % realpath .
> /home/dalamagkidis/tmp/repo
> 
> It appears that git-config and git-send-email parse the gitdir slightly
> differently when it comes to symlinks. More specifically git-send-email uses
> the realpath of the repository to determine which configuration to use. It
> also explains why nobody came across this problem before.

Ah, that's interesting. In both cases it's git-config who is doing the path comparison. And it should be happy with either form due to 0624c63ce6 (config: match both symlink & realpath versions in IncludeIf.gitdir:*, 2017-05-16).

But if send-email is normalizing the path and setting $GIT_DIR before we even hit git-config, then that would fool it (git-config never even sees the symlinked path). And that seems to be the case, which is due to the Git.pm perl module. Running:

  git init repo
  ln -s repo link
  cd link
  git config alias.env '!echo $GIT_DIR'
  perl -MGit -le '
    my $repo = Git->repository();
    print "env=", $repo->command(qw(env));
    print "resolved=", $repo->command(qw(rev-parse --git-dir));
  '

gives me:

  env=/home/peff/tmp/repo/.git
  resolved=/home/peff/tmp/repo/.git

I'd argue that Git.pm probably shouldn't be setting $GIT_DIR at all when we've auto-discovered the repo from the current directory (instead all of the sub-programs should just do their own auto-discovery). But even if we feed the constructor another repository path, it probably should be keeping what it puts in $GIT_DIR as close to what it was original given.

I'll admit I'm slightly afraid to touch Git.pm at all, though. It's old, rarely touched code that I suspect has poor test coverage. But I'll cc Ævar, who was the most recent brave person. ;)

-Peff