git-send-email does not use conditional configuration

Hello,

In my git configuration, I have an includeif section for work related repositories that configures the user and sendemail sections.

I can verify that the configuration is read correctly by git:

% git config --get-regex "sendemail.*" sendemail.smtpencryption tls sendemail.smtpserver smtp.office365.com sendemail.smtpserverport 587 sendemail.smtpuser dalamagkidis@work.com

But when running git send-email the default sendmail is used:

% git send-email --dry-run 0001*
[...]
Dry-OK. Log says:
Sendmail: /usr/sbin/sendmail -i test@example.com dalamagkidis@work.com
From: Konstantinos Dalamagkidis <konstantinos@dalamagkidis.info>
To: test@example.com
Cc: Konstantinos Dalamagkidis <dalamagkidis@work.com>
[...]

If I move the sendemail section to the main gitconfig file, it works as expected. I normally use v2.20.1, but I could also reproduce this with v2.23.

Rgds Konstantinos

On Wed, Sep 11, 2019 at 08:14:45AM +0200, Konstantinos Dalamagkidis wrote:

What kind of includeIf are you using? Does it work with an unconditional include? This seems to work for me:

  $ git config --global include.path one
  $ git config --file ~/one sendemail.smtpserver one.example.com
  $ git send-email --dry-run -1 --to nobody | grep ^Server
  Server: one.example.com

  $ git config --global includeIf.gitdir:$PWD/.path two
  $ git config --file ~/two sendemail.smtpserver two.example.com
  $ git send-email --dry-run -1 --to nobody | grep ^Server
  Server: two.example.com

I.e. both unconditional and gitdir includes work for me. If you do something similar, what output do you get?

Thanks for this output. That rules out that "git config" is somehow misbehaving in a way that normal internal config lookups wouldn't.

The rest of git-config should behave the same, but you could also try:

  git config --get sendemail.smtpserver

which is what send-email will actually run (you can run send-email with GIT_TRACE=1 to see the full set of commands if you want to try them manually).

-Peff

On 9/11/19 4:08 PM, Jeff King wrote:

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.

Rgds Konstantinos

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

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