search

MestreLion / git-tools

Assorted git tools, including git-restore-mtime
GNU General Public License v3.0
295 stars 74 forks source link

Ignore GPG signatures when parsing git logs #80

Closed mervynfoxe closed 2 months ago

mervynfoxe commented 2 months ago

In Git v2.10, the option log.showSignature was introduced to imply a --show-signature flag for all calls to log, show, and whatchanged. If a user has this option enabled, and the most recent commit for any checked file was GPG-signed, this can lead to an uncaught exception when parsing the log, as instead of an expected author/commit time, the first line contains the GPG signature output.

$ git restore-mtime --version
git-restore-mtime version 2022.12

$ git restore-mtime
1 files to be processed in work dir
Traceback (most recent call last):
  File "/opt/homebrew/bin/git-restore-mtime", line 594, in <module>
    sys.exit(main())
             ^^^^^^
  File "/opt/homebrew/bin/git-restore-mtime", line 530, in main
    parse_log(filelist, dirlist, stats, git, args.merge, args.pathspec)
  File "/opt/homebrew/bin/git-restore-mtime", line 389, in parse_log
    mtime = int(line)
            ^^^^^^^^^
ValueError: invalid literal for int() with base 10: 'gpg: Signature made Tue Sep 10 15:24:25 2024 EDT'

This fix simply enforces the --no-show-signature flag in the call to git whatchanged so that regardless of user config, GPG signatures are not checked and the first line of the returned string is indeed the commit timestamp.

mervynfoxe commented 2 months ago

Noted just now that the project readme says tested in Git 2.17.1 and prior rather than later, d'oh. This change will throw an unrecognized argument error if run with Git 2.9.x and below. If the readme is accurate and pre-2.10.0 versions of Git should be supported I can push up a very basic version check/conditional for including the flag, otherwise I'm not sure if you'd like to explore other options for solving this issue.

MestreLion commented 2 months ago

What a great addition, thanks!

MestreLion commented 2 months ago

Noted just now that the project readme says tested in Git 2.17.1 and prior rather than later, d'oh.

Yes, I admit the wording is unusual, it means is something like "we officially test on 2.17.1, and only supports that and later versions, but as this tool was created in 2012 it probably still works with older versions"

I've consulted Git dates, and 2.10 was released in 2016. Even the now-ancient Ubuntu 18.04 LTS has 2.17, so I believe no version check is required.