[BUG] gpg.program: '~' not expanded to home directory

`gpg.program` treats a leading ‘~’ literally, unlike other path options such as `core.excludesfile`.

Error:

    fatal: cannot exec '~/.local/bin/mygpg': No such file or directory

Reproducer:

    ln -s "$(command -v gpg)" ~/.local/bin/mygpg
    git config gpg.program '~/.local/bin/mygpg'
    git commit -S -m "test"   # fails as above

Expected: Git should expand ‘~’ to $HOME.
Work-around: have to use an absolute path

This allows using a custom gpg program under the user's home directory by specifying a path starting with '~'

[gpg]
        program = "~/.local/bin/mygpg"

Signed-off-by: Jonas Brandstötter <jonas.brandstoetter@gmx.at>
---
First time interacting with a project via a mailing list. Do let me know if
I did something very dumb.

  Jonas
 Documentation/config/gpg.adoc | 2 +-
 gpg-interface.c               | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Jonas Brandstötter <jonas.brandstoetter@gmx.at> writes:

Thanks. The update to the codumentation to explicitly say that the variable is about "pathname" is a very nice touch, and the code change is trivially correct, I guess.

I wonder if we can have some test to protect this feature from broken by mistake, though.

Allows users to specify a custom gpg program in their home directory.

V2 adds test cases for when the gpg program is not set as an absolute path. The test for gpg in a home directory feels a bit wonky to me, because it assumes that `~` is an alias for `$HOME` and just overriding that variable with the test directory. But short of creating a user while running the tests, this is the best solution I could come up with.

Jonas Brandstötter (2):
  gpg-interface: expand gpg.program as a path
  t7510: add test cases for non-absolute gpg program

 Documentation/config/gpg.adoc |  2 +-
 gpg-interface.c               |  2 +-
 t/t7510-signed-commit.sh      | 12 +++++++++++-
 3 files changed, 13 insertions(+), 3 deletions(-)

Range-diff against v1: 1: b551903c16 = 1: b551903c16 gpg-interface: expand gpg.program as a path -: ---------- > 2: ca22bf2ee6 t7510: add test cases for non-absolute gpg program -- 2.50.1

Jonas Brandstötter <jonas.brandstoetter@gmx.at> writes:

The first iteration of the patch was merged in the 'next' branch long time ago, and then to the 'master' branch already. It is way too late to wholesale replace the patch from the previous iteration.

It appears the first patch hasn't changed at all, so I'll just take the second patch as a separate, follow-up topic to add a missing test for already-graduated topic.

Thanks!

This allows using a custom gpg program under the user's home directory by specifying a path starting with '~'

[gpg]
        program = "~/.local/bin/mygpg"

Signed-off-by: Jonas Brandstötter <jonas.brandstoetter@gmx.at>
---
 Documentation/config/gpg.adoc | 2 +-
 gpg-interface.c               | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

These cases cover scenarios where `gpg.program` is set as a program in `$PATH` or as a path relative to the user's home directory.

Signed-off-by: Jonas Brandstötter <jonas.brandstoetter@gmx.at>
---
 t/t7510-signed-commit.sh | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

On Tue, Jul 22, 2025 at 09:09:22PM +0200, Jonas Brandstötter wrote:

This second test seems to fail on Windows. E.g., in this CI job:

  https://github.com/git/git/actions/runs/16509422831/job/46688307091

Right before the failure, the trace shows that we are setting PATH like this:

  ++env 'PATH=D:/a/git/git/t/trash directory.t7510-signed-commit:/d/a/git/git:/d/a/git/git/t/helper:/c/Users/runneradmin/path:/mingw64/bin:/usr/bin/:/usr/bin/core_perl:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem'

Should it be "/d/a/git/git/..." instead of "D:/a/git/git/..."? Which we could get by using $PWD, I think.

The earlier one using $HOME uses D:/, but this one is different because colons are meaningful separators in $PATH.

-Peff

On Fri, Jul 25, 2025 at 12:30:43AM -0400, Jeff King wrote:

Yeah, that is it. I found a commit with some prior art, and here is the passing CI result:

  https://github.com/peff/git/actions/runs/16513873854

I do wonder if that one needs to set $HOME at all. The test harness already points $HOME to the trash directory. But maybe it has value to document the expectation.

Anyway, here is the fix as a patch on top of jb/t7510-gpg-program-path. I am also happy for it to be squashed in, since I think the topic is not yet in 'next'.

-- >8 --
Subject: [PATCH] t7510: use $PWD instead of $(pwd) inside PATH

On Windows, $(pwd) will give us a Windows-style path like "D:/foo". Putting that into $PATH confuses anybody parsing that variable, since colon is a separator character in $PATH. Instead, we should use the Unix-style value we get from $PWD ("/d/foo").

This is similar to the cases fixed by 71dd50472d (t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables, 2016-11-11).

Signed-off-by: Jeff King <peff@peff.net>
---
 t/t7510-signed-commit.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Jeff King <peff@peff.net> writes:

Here is what I have on top of the posted patches. If today's integration goes well, I plan to merge it to 'next'; the rest of the series is already in 'next'.

---- >8 ----
Subject: [PATCH] t7510: Windows fix

$PATH and $(pwd) does not mix very well, because PATH is a colon separated list of directories, but on Windows port of the shell Git-for-Windows uses, $(pwd) looks like "D:/path/to/a/directory".

With $PWD, we would get /d/path/to/a/directory instead, which would fit better on $PATH. This broke Windows CI job.

While at it, drop unnecessary use of "env VAR=VAL" before "git commit"; one-shot export "VAR=VAL git commit" is sufficient.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t7510-signed-commit.sh | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

On Mon, Jul 28, 2025 at 05:05:46PM -0700, Junio C Hamano wrote:

Looks good. Not sure if you saw the patch I posted in this thread. It's roughly the same as yours, though I didn't drop the useless "env" (which I agree is useless).

I did reference 71dd50472d (t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables, 2016-11-11) to try to give more explanation of the two different sources. But re-reading it, it actually doesn't really clarify much. ;) So maybe not worth worrying about.

-Peff

Jeff King <peff@peff.net> writes:

Ah, sorry, no I missed it.  Will replace with your variant.

Thanks.

Ross MacArthur <ross@macarthur.io> writes:

I think that is correct; I do not think gpg.program is to give a path to the program, so comparison with core.excludesfile is probably not so appropriate.

It gives a command line, e.g. "mysign --compat=gnupg", where the program "mysign" somewhere on your path can be told to behave in a way compatible to GPG when a command line option "--compat=gnupg" is given. We further append our own command line options when we invoke this command, like the "git config --help" on this variable says. When we want to verify GPG signature $signature in a file $file, for example, instead of running gpg, we would run:

	mysign --compat=gnupg --verify $signature - <$file

So this expectation does not quite hold true.

I wonder if letting your shell to handle the tilde expansion would make it work, though. Continuing with the example, it may look something like this, perhaps?

 $ git config set gpg.program "sh -c '~/mysign --compat=gnupg \"\$@\"' -"

On Jul 11 2025, Junio C Hamano wrote:

gpg-interface does not use the shell to run gpg.program, so this won't work.

$ git config gpg.program "echo --compat=gnupg" $ git commit -m foo -S error: cannot run echo --compat=gnupg: No such file or directory error: gpg failed to sign the data: (no gpg output) fatal: failed to write commit object

Andreas Schwab <schwab@linux-m68k.org> writes:

You're right.  Thanks for correcting me.

I should have gone to the code I wrote instead of answering from what I didn't see (namely, the word "pathname") in the documentation X-<.