path: root/perl
AgeCommit message (Collapse)Author trust rev-parse to find bare repositoriesJeff King
When initializing a repository object, we run "git rev-parse --git-dir" to let the C version of Git find the correct directory. But curiously, if this fails we don't automatically say "not a git repository". Instead, we do our own pure-perl check to see if we're in a bare repository. This makes little sense, as rev-parse will report both bare and non-bare directories. This logic comes from d5c7721d58 ( Add support for subdirectories inside of working copies, 2006-06-24), but I don't see any reason given why we can't just rely on rev-parse. Worse, because we treat any non-error response from rev-parse as a non-bare repository, we'll erroneously set the object's WorkingCopy, even in a bare repository. But it gets worse. Since 8959555cee (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02), it's actively wrong (and dangerous). The perl code doesn't implement the same ownership checks. And worse, after "finding" the bare repository, it sets GIT_DIR in the environment, which tells any subsequent Git commands that we've confirmed the directory is OK, and to trust us. I.e., it re-opens the vulnerability plugged by 8959555cee when using's repository discovery code. We can fix this by just relying on rev-parse to tell us when we're not in a repository, which fixes the vulnerability. Furthermore, we'll ask its --is-bare-repository function to tell us if we're bare or not, and rely on that. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <> add semicolon after catch statementMichael McClimon
When attempting to initialize a repository object in an unsafe directory, a syntax error is reported (Can't use string as a HASH ref while strict refs in use). Fix this runtime error by adding the required semicolon after the catch statement. Without the semicolon, the result of the following line (i.e., the result of Cwd::abs_path) is passed as the third argument to's catch function. That function expects that its third argument, $clauses, is a hash reference, and trying to access a string as a hash reference is a fatal error. [1] Reported-by: Hank Leininger <> Signed-off-by: Michael McClimon <> Signed-off-by: Junio C Hamano <>
2022-02-01perl don't ignore signalled failure in _cmd_close()Ævar Arnfjörð Bjarmason
Fix misbehavior in that dates back to the very first version of the library in git.git added in b1edc53d062 (Introduce (v4), 2006-06-24). When we fail to execute a command we shouldn't ignore all signals, those can happen e.g. if abort() is called, or if the command segfaults. Because of this we'd consider e.g. a command that died due to LSAN exiting with abort() successful, as is the case with the tests listed as running successfully with SANITIZE=leak in 9081a421a6d (checkout: fix "branch info" memory leaks, 2021-11-16). We did run them successfully, but only because we ignored these errors. This was then made worse by the use of "abort_on_error=1" for LSAN added in 85b81b35ff9 (test-lib: set LSAN_OPTIONS to abort by default, 2017-09-05). Doing that makes sense, but without providing that option we'd have a "$? >> 8" of "23" on failure, with abort_on_error=1 we'll get "0". All of our tests pass even without the SIGPIPE exception being added here, but as the code appears to have been trying to ignore it let's keep ignoring it for now. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-10-29tests: disable fsync everywhereEric Wong
The "GIT_TEST_FSYNC" environment variable now exists for disabling fsync() even on packfiles and other "critical" data. Running "make test -j8 NO_SVN_TESTS=1" on a noisy 8-core system on an HDD, test runtime drops from ~4 minutes down to ~3 minutes. Using "GIT_TEST_FSYNC=1" re-enables fsync() for comparison purposes. SVN interopability tests are minimally affected since SVN will still use fsync in various places. This will also be useful for 3rd-party tools which create throwaway git repositories of temporary data, but remains undocumented for end users. Signed-off-by: Eric Wong <> Signed-off-by: Junio C Hamano <>
2021-07-22Merge branch 'ab/send-email-optim'Junio C Hamano
"git send-email" optimization. * ab/send-email-optim: perl: nano-optimize by replacing Cwd::cwd() with Cwd::getcwd() send-email: move trivial config handling to Perl perl: lazily load some common setup code send-email: lazily load modules for a big speedup send-email: get rid of indirect object syntax send-email: use function syntax instead of barewords send-email: lazily shell out to "git var" send-email: lazily load config for a big speedup send-email: copy "config_regxp" into git-send-email.perl send-email: refactor sendemail.smtpencryption config parsing send-email: remove non-working support for "sendemail.smtpssl" send-email tests: test for boolean variables without a value send-email tests: support GIT_TEST_PERL_FATAL_WARNINGS=true
2021-06-14Merge branch 'so/log-m-implies-p'Junio C Hamano
The "-m" option in "git log -m" that does not specify which format, if any, of diff is desired did not have any visible effect; it now implies some form of diff (by default "--patch") is produced. * so/log-m-implies-p: diff-merges: let "-m" imply "-p" diff-merges: rename "combined_imply_patch" to "merges_imply_patch" stash list: stop passing "-m" to "git log" git-svn: stop passing "-m" to "git rev-list" diff-merges: move specific diff-index "-m" handling to diff-index t4013: test "git diff-index -m" t4013: test "git diff-tree -m" t4013: test "git log -m --stat" t4013: test "git log -m --raw" t4013: test that "-m" alone has no effect in "git log"
2021-05-28perl: nano-optimize by replacing Cwd::cwd() with Cwd::getcwd()Ævar Arnfjörð Bjarmason
It has been pointed out[1] that cwd() invokes "pwd(1)" while getcwd() is a Perl-native XS function. For what we're using these for we can use getcwd(). The performance difference is miniscule, we're saving on the order of a millisecond or so, see [2] below for the benchmark. I don't think this matters in practice for optimizing git-send-email or perl execution (unlike the patches leading up to this one). But let's do it regardless of that, if only so we don't have to think about this as a low-hanging fruit anymore. 1. 2. $ perl -MBenchmark=:all -MCwd -wE 'cmpthese(10000, { getcwd => sub { getcwd }, cwd => sub { cwd }, pwd => sub { system "pwd >/dev/null" }})' (warning: too few iterations for a reliable count) Rate pwd cwd getcwd pwd 982/s -- -48% -100% cwd 1890/s 92% -- -100% getcwd 10000000000000000000/s 1018000000000000000% 529000000000000064% - Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-05-28perl: lazily load some common setup codeÆvar Arnfjörð Bjarmason
Instead of unconditionally requiring modules such as File::Spec, let's only load them when needed. This speeds up code that only needs a subset of the features provides. This brings a plain invocation of "git send-email" down from 52/37 loaded modules under NO_GETTEXT=[|Y] to 39/18, and it now takes ~60-~70ms instead of ~80-~90ms. The runtime of test is down to ~13s from ~15s. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-05-27Merge branch 'ab/send-email-inline-hooks-path'Junio C Hamano
Code simplification. * ab/send-email-inline-hooks-path: send-email: move "hooks_path" invocation to git-send-email.perl send-email: don't needlessly abs_path() the core.hooksPath
2021-05-27send-email: move "hooks_path" invocation to git-send-email.perlÆvar Arnfjörð Bjarmason
Move the newly added "hooks_path" API in to its only user in git-send-email.perl. This was added in c8243933c74 (git-send-email: Respect core.hooksPath setting, 2021-03-23), meaning that it hasn't yet made it into a non-rc release of git. The consensus with is that we need to be considerate of out-of-tree users who treat it as a public documented interface. We should therefore be less willing to add new functionality to it, least we be stuck supporting it after our own uses for it disappear. In this case the git-send-email.perl hook invocation will probably be replaced by a future "git hook run" command, and in the commit preceding this one the "hooks_path" become nothing but a trivial wrapper for "rev-parse --git-path hooks" anyway (with no Cwd::abs_path() call), so let's just inline this command in git-send-email.perl itself. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-05-27send-email: don't needlessly abs_path() the core.hooksPathÆvar Arnfjörð Bjarmason
In c8243933c74 (git-send-email: Respect core.hooksPath setting, 2021-03-23) we started supporting core.hooksPath in "send-email". It's been reported that on Windows[1] doing this by calling abs_path() results in different canonicalizations of the absolute path. This wasn't an issue in c8243933c74 itself, but was revealed by my ea7811b37e0 (git-send-email: improve --validate error output, 2021-04-06) when we started emitting the path to the hook, which was previously only internal to git-send-email.perl. The just-landed 53753a37d09 ( fix expected absolute paths on Windows, 2021-05-24) narrowly fixed this issue, but I believe we can do better here. We should not be relying on whatever changes Perl's abs_path() makes to the path "rev-parse --git-path hooks" hands to us. Let's instead trust it, and hand it to Perl's system() in git-send-email.perl. It will handle either a relative or absolute path. So let's revert most of 53753a37d09 and just have "hooks_path" return what we get from "rev-parse" directly without modification. This has the added benefit of making the error message friendlier in the common case, we'll no longer print an absolute path for repository-local hook errors. 1. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-05-21git-svn: stop passing "-m" to "git rev-list"Sergey Organov
rev-list doesn't utilize -m. It happens to eat it silently, so this bug went unnoticed. Signed-off-by: Sergey Organov <> Signed-off-by: Junio C Hamano <>
2021-05-06perl: use mock i18n functions under NO_GETTEXT=YÆvar Arnfjörð Bjarmason
Change the logic of the i18n functions I added in 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18) to use pass-through functions when NO_GETTEXT is defined. This speeds up the compilation time of commands that use this library when NO_GETTEXT=Y is in effect. Loading it and is around 20ms on my machine, whereas it takes 2ms to just instantiate perl itself. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-03-23git-send-email: Respect core.hooksPath settingRobert Foss
get-send-email currently makes the assumption that the 'sendemail-validate' hook exists inside of the repository. Since the introduction of 'core.hooksPath' configuration option in 867ad08a261 (hooks: allow customizing where the hook directory is, 2016-05-04), this is no longer true. Instead of assuming a hardcoded repo relative path, query git for the actual path of the hooks directory. Signed-off-by: Robert Foss <> Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2020-11-09Merge branch 'jk/perl-warning'Junio C Hamano
Dev support. * jk/perl-warning: perl: check for perl warnings while running tests
2020-11-02Merge branch 'bc/svn-hash-oid-fix'Junio C Hamano
A recent oid->hash conversion missed one spot, breaking "git svn". * bc/svn-hash-oid-fix: svn: use correct variable name for short OID
2020-10-22perl: check for perl warnings while running testsJeff King
We set "use warnings" in most of our perl code to catch problems. But as the name implies, warnings just emit a message to stderr and don't otherwise affect the program. So our tests are quite likely to miss that warnings are being spewed, as most of them do not look at stderr. We could ask perl to make all warnings fatal, but this is likely annoying for non-developers, who would rather have a running program with a warning than something that refuses to work at all. So instead, let's teach the perl code to respect an environment variable (GIT_PERL_FATAL_WARNINGS) to increase the severity of the warnings. This can be set for day-to-day running if people want to be really pedantic, but the primary use is to trigger it within the test suite. We could also trigger that for every test run, but likewise even the tests failing may be annoying to distro builders, etc (just as -Werror would be for compiling C code). So we'll tie it to a special test-mode variable (GIT_TEST_PERL_FATAL_WARNINGS) that can be set in the environment or as a Makefile knob, and we'll automatically turn the knob when DEVELOPER=1 is set. That should give developers and CI the more careful view without disrupting normal users or packagers. Note that the mapping from the GIT_TEST_* form to the GIT_* form in is necessary even if they had the same name: the perl scripts need it to be normalized to a perl truth value, and we also have to make sure it's exported (we might have gotten it from the environment, but we might also have gotten it from GIT-BUILD-OPTIONS directly). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2020-10-22svn: use correct variable name for short OIDbrian m. carlson
The commit 9ab33150a0 ("perl: create and switch variables for hash constants", 2020-06-22) converted each instance of the variable $sha1_short into $oid_short in the Subversion code, since git-svn now understands SHA-256. However, one conversion was missed. As a result, Perl complains about the use of this variable: Use of uninitialized value $sha1_short in regexp compilation at /usr/lib64/perl5/vendor_perl/5.30.3/Git/SVN/ line 301, <$fh> line 6. Because we're parsing raw diff output here, the likelihood is very low that we'll actually misparse the data, since the only lines we're going to get starting with colons are the ones we're expecting. Even if we had a newline in a path, we'd end up with a quoted path. Our regex is just less strict than we'd like it to be. However, it's obviously undesirable that our code is emitting Perl warnings, so let's convert it to use the proper variable name. Reported-by: Nikos Chantziaras <> Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2020-07-24git-send-email: die if sendmail.* config is setDrew DeVault
I've seen several people mis-configure git send-email on their first attempt because they set the sendmail.* config options - not sendemail.*. This patch detects this mistake and bails out with a friendly warning. Signed-off-by: Drew DeVault <> Signed-off-by: Junio C Hamano <>
2020-06-22perl: make SVN code hash independentbrian m. carlson
There are several places throughout git-svn that use various hard-coded constants. For matching object IDs, use the $oid variable. Compute the record size we use for our revision storage based on the object ID. When parsing the revision map format, use a wildcard in the pack format since we know that the data we're parsing is always exactly the record size. This lets us continue to use a constant for the pack format. Finally, update several comments to reflect the fact that an object ID may be of one of multiple sizes. Signed-off-by: brian m. carlson <> Acked-by: Eric Wong <> Signed-off-by: Junio C Hamano <>
2020-06-22perl: make Git::IndexInfo work with SHA-256brian m. carlson
Most of the Git modules, git-svn excepted, don't know anything about the hash algorithm and mostly work. However, when we're printing an all-zero object ID in Git::IndexInfo, we need to know the hash length. Since we don't want to change the API to have that information passed in, let's query the config to find the hash algorithm and compute the right value. Signed-off-by: brian m. carlson <> Acked-by: Eric Wong <> Signed-off-by: Junio C Hamano <>
2020-06-22perl: create and switch variables for hash constantsbrian m. carlson
git-svn has several variables for SHA-1 constants, including short hash values and full length hash values. Since these are no longer SHA-1 specific, let's start them with "oid" instead of "sha1". Add a constant, oid_length, which is the length of the hash algorithm in use in hex. We use the hex version because overwhelmingly that's what's used by git-svn. We don't currently set oid_length based on the repository algorithm, but we will in a future commit. Signed-off-by: brian m. carlson <> Acked-by: Eric Wong <> Signed-off-by: Junio C Hamano <>
2019-11-07Fix spelling errors in documentation outside of Documentation/Elijah Newren
Reported-by: Jens Schleusener <> Signed-off-by: Elijah Newren <> Signed-off-by: Junio C Hamano <>
2019-09-28git-svn: trim leading and trailing whitespaces in author nameTobias Klauser
In some cases, the svn author names might contain leading or trailing whitespaces, leading to messages such as: Author: user1 not defined in authors.txt (the trailing newline leads to the line break). The user "user1" is defined in authors.txt though, e.g. user1 = User <> Fix this by trimming the author name retreived from svn before using it in check_author. Helped-by: Eric Sunshine <> Signed-off-by: Tobias Klauser <> Signed-off-by: Junio C Hamano <> make hash size independentbrian m. carlson
The cat_blob function was matching on exactly 40 hex characters. This won't work with SHA-256, which uses 64-character hex object IDs. While it should be fine to simply match any number of hex characters since the output is space delimited, be extra safe by matching either exactly 40 or exactly 64 hex characters. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2018-05-08Merge branch 'ab/git-svn-get-record-typofix'Junio C Hamano
"git svn" had a minor thinko/typo which has been fixed. * ab/git-svn-get-record-typofix: git-svn: avoid warning on undef readline()
2018-05-08Merge branch 'dj/runtime-prefix'Junio C Hamano
A build-time option has been added to allow Git to be told to refer to its associated files relative to the main binary, in the same way that has been possible on Windows for quite some time, for Linux, BSDs and Darwin. * dj/runtime-prefix: Makefile: quote $INSTLIBDIR when passing it to sed Makefile: remove unused @@PERLLIBDIR@@ substitution variable mingw/msvc: use the new-style RUNTIME_PREFIX helper exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows exec_cmd: RUNTIME_PREFIX on some POSIX systems Makefile: add Perl runtime prefix support Makefile: generate Perl header from template file
2018-04-11Makefile: add Perl runtime prefix supportDan Jacques
Broaden the RUNTIME_PREFIX flag to configure Git's Perl scripts to locate the Git installation's Perl support libraries by resolving against the script's path, rather than hard-coding that path at build-time. Hard-coding at build time worked on previous RUNTIME_PREFIX configurations (i.e., Windows) because the Perl scripts were run within a virtual filesystem whose paths were consistent regardless of the location of the actual installation. This will no longer be the case for non-Windows RUNTIME_PREFIX users. When enabled, RUNTIME_PREFIX now requires Perl's system paths to be expressed relative to a common installation directory in the Makefile, and uses that relationship to locate support files based on the known starting point of the script being executed, much like RUNTIME_PREFIX does for the Git binary. This change enables Git's Perl scripts to work when their Git installation is relocated or moved to another system, even when they are not in a virtual filesystem environment. Signed-off-by: Dan Jacques <> Thanks-to: Ævar Arnfjörð Bjarmason <> Thanks-to: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-04-11Makefile: generate Perl header from template fileDan Jacques
Currently, the generated Perl script headers are emitted by commands in the Makefile. This mechanism restricts options to introduce alternative header content, needed by Perl runtime prefix support, and obscures the origin of the Perl script header. Change the Makefile to generate a header by processing a template file and move the header content into the "perl/" subdirectory. The generated header content will now be stored in the "GIT-PERL-HEADER" file. This allows the content of the Perl header to be controlled by changing the path of the template in the Makefile. Signed-off-by: Dan Jacques <> Thanks-to: Ævar Arnfjörð Bjarmason <> Thanks-to: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-04-09git-svn: avoid warning on undef readline()Ævar Arnfjörð Bjarmason
Change code in that sometimes calls chomp() on undef to only do so the value is defined. This code has been chomping undef values ever since it was added in b26098fc2f ("git-svn: reduce scope of input record separator change", 2016-10-14), but started warning due to the introduction of "use warnings" to in my f0e19cb7ce (" add the "use warnings" pragma", 2018-02-25) released with 2.17.0. Since this function will return undef in those cases it's still possible that the code using it will warn if it does a chomp of its own, as the code added in b26098fc2f ("git-svn: reduce scope of input record separator change", 2016-10-14) might do, but since git-svn has "use warnings" already that's clearly not a codepath that's going to warn. See for the original report. Reported-by: Joseph Mingrone <> Signed-off-by: Ævar Arnfjörð Bjarmason <> Improved-by: Eric Wong <> Signed-off-by: Junio C Hamano <>
2018-04-05git-svn: allow empty email-address using authors-prog and authors-fileAndreas Heiduk
The email address in --authors-file and --authors-prog can be empty but git-svn translated it into a fictional email address in the form jondoe <jondoe@6aafaa21e0fb4338a68ab372a049893d> containing the SVN repository UUID. Now git-svn behaves like git-commit: If the email is *explicitly* set to the empty string using '<>', the commit does not contain an email address, only the name: jondoe <> Allowing to remove the email address *intentionally* prevents automatic systems from sending emails to those fictional addresses and avoids cluttering the log output with unnecessary stuff. Signed-off-by: Andreas Heiduk <> Signed-off-by: Eric Wong <>
2018-03-15Merge branch 'ab/perl-fixes'Junio C Hamano
Clean-up to various pieces of Perl code we have. * ab/perl-fixes: perl Git::LoadCPAN: emit better errors under NO_PERL_CPAN_FALLBACKS Makefile: add NO_PERL_CPAN_FALLBACKS knob perl: move the perl/Git/FromCPAN tree to perl/FromCPAN perl: generalize the Git::LoadCPAN facility perl: move CPAN loader wrappers to another namespace perl: update our copy of Mail::Address perl: update our ancient copy of git-send-email: unconditionally use Net::{SMTP,Domain} hard-depend on the File::{Temp,Spec} modules gitweb: hard-depend on the Digest::MD5 5.8 module add the "use warnings" pragma remove redundant "use strict" from sub-package perl: *.pm files should not have the executable bit
2018-03-06Merge branch 'bw/perl-timegm-timelocal-fix'Junio C Hamano
Y2k20 fix ;-) for our perl scripts. * bw/perl-timegm-timelocal-fix: perl: call timegm and timelocal with 4-digit year
2018-03-05perl Git::LoadCPAN: emit better errors under NO_PERL_CPAN_FALLBACKSÆvar Arnfjörð Bjarmason
Before my 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple make rules", 2017-12-10) on an OS package that removed the copy we carried around manually removing the OS's would yield: $ git add -p Can't locate in @INC (you may need to install the Error module) [...] Now, before this change we'll instead emit this more cryptic error: $ git add -p BUG: '/usr/share/perl5/Git/FromCPAN' should be a directory! at /usr/share/perl5/Git/ line 36. This is a confusing error. Now if the new NO_PERL_CPAN_FALLBACKS option is specified and we can't find the module we'll instead emit: $ /tmp/git/bin/git add -p BUG: The 'Error' module is not here, but NO_PERL_CPAN_FALLBACKS was set! [...] Where [...] is the lengthy explanation seen in the change below, which explains what the potential breakage is, and how to fix it. The reason for checking @@NO_PERL_CPAN_FALLBACKS@@] against the empty string in Perl is as opposed to checking for a boolean value is that that's (as far as I can tell) make's idea of a string that's set, and e.g. NO_PERL_CPAN_FALLBACKS=0 is enough to set NO_PERL_CPAN_FALLBACKS. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-03-05perl: move the perl/Git/FromCPAN tree to perl/FromCPANÆvar Arnfjörð Bjarmason
Move the CPAN modules that have lived under perl/Git/FromCPAN since my 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple make rules", 2017-12-10) to perl/FromCPAN. A subsequent change will teach the Makefile to only install these copies of CPAN modules if a flag that distro packagers would like to set isn't set. Due to how the wildcard globbing is being done it's much easier to accomplish that if they're moved to their own directory. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-03-05perl: generalize the Git::LoadCPAN facilityÆvar Arnfjörð Bjarmason
Change the two wrappers that load from CPAN (local OS) or our own copy to do so via the same codepath. I added the wrapper in 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple make rules", 2017-12-10), and shortly afterwards Matthieu Moy added a wrapper for Mail::Address in bd869f67b9 ("send-email: add and use a local copy of Mail::Address", 2018-01-05). His loader was simpler since Mail::Address doesn't have an "import" method, but didn't do the same sanity checking; For example, a missing FromCPAN directory (which OS packages are likely not to have) wouldn't be explicitly warned about as a "BUG: ...". Update both to use a common implementation based on the previous loader. Which has been amended to take the module to load as parameter, as well as whether or not that module has an import method. This loader should be generic enough to handle almost all CPAN modules out there, some use some crazy loading magic and wouldn't like being wrapped like this, but that would be immediately obvious, and we'd find out right away since the module wouldn't work at all. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-03-05perl: move CPAN loader wrappers to another namespaceÆvar Arnfjörð Bjarmason
Move the Git::Error and Git::Mail::Address wrappers to the Git::LoadCPAN::Loader::* namespace, e.g. Git::LoadCPAN::Error. That module will then either load Error from CPAN (if installed on the OS), or use Git::FromCPAN::Error. When I added the Error wrapper in 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple make rules", 2017-12-10) I didn't think about how confusing it would be to have these modules sitting in the same tree as our normal modules. Let's put these all into Git::{Load,From}CPAN::* to clearly distinguish them from the rest. This also makes things a bit less confusing since there was already a Git::Error namespace ever since 8b9150e3e3 (" Handle failed commands' output", 2006-06-24). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-03-05perl: update our copy of Mail::AddressÆvar Arnfjörð Bjarmason
Update our copy of Mail::Address from 2.19 (Aug 22, 2017) to 2.20 (Jan 23, 2018). Like the preceding update this is done simply to keep up-to-date with upstream, and as can be shown from the diff there's no functional changes. The updated source was retrieved from Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-03-05perl: update our ancient copy of Error.pmÆvar Arnfjörð Bjarmason
The shipped with Git as a fallback if there was no on the system was released in April 2006. There's been dozens of releases since then, the latest at August 7, 2017. Let's update to that. I don't know of anything we need from this new release or which this fixes. This change is simply a matter of keeping up with upstream. Before this users who'd install git via their package system would get an up-to-date, but if it's installed from source they'd get one more than a decade old. This undoes a local hack we'd accumulated in 96bc4de85c ("Eliminate Scalar::Util usage from", 2006-07-26), it's been redundant since my d48b284183 ("perl: bump the required Perl version to 5.8 from 5.6.[21]", 2010-09-24). This also undoes 3a51467b94 ("Typo fix: replacing it's -> its", 2013-04-13). This is the Nth time I find that some upstream code of ours (in contrib/, in sha1dc/ and now in perl/ ...) has diverged from upstream because of some tree-wide typo fixing. Let's not do those fixes against upstream projects, it's more valuable that we have a 1=1 mapping to upstream than to fix typos in docs we never even generate from this code. If someone wants to fix typos in them fine, but they should do it with a patch to upstream which git.git can then incorporate. The upstream code doesn't cleanly pass a --check, so I'm adding a .gitattributes file for similar reasons as done for sha1dc in 5d184f468e ("sha1dc: ignore indent-with-non-tab whitespace violations", 2017-06-06). The updated source was retrieved from Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <> hard-depend on the File::{Temp,Spec} modulesÆvar Arnfjörð Bjarmason
Since my d48b284183 ("perl: bump the required Perl version to 5.8 from 5.6.[21]", 2010-09-24), we've depended on 5.8, so there's no reason to conditionally require File::Temp and File::Spec anymore. They were first released with perl versions v5.6.1 and 5.00405, respectively. This code was originally added in c14c8ceb13 (" Make File::Spec and File::Temp requirement lazy", 2008-08-15), presumably to make work on 5.6.0. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <> add the "use warnings" pragmaÆvar Arnfjörð Bjarmason
Amend to load the "warnings" pragma like the rest of the code in perl/ in addition to the existing "strict" pragma. This is considered the bare minimum best practice in Perl. Ever since this code was introduced in b1edc53d06 ("Introduce (v4)", 2006-06-24) it's only been using "strict", not "warnings". This leaves contrib/buildsystems/Generators/{QMake,VCproj}.pm and contrib/mw-to-git/Git/ without "use warnings". Amending those would be a sensible follow-up change, but I don't have an easy way to test those so I'm not changing them. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <> remove redundant "use strict" from sub-packageÆvar Arnfjörð Bjarmason
In Perl the "use strict/warnings" pragmas are lexical, thus there's no reason to do: package Foo; use strict; package Bar; use strict; $x = 5; To satisfy the desire that the undeclared $x variable will be spotted at compile-time. It's enough to include the first "use strict". This functionally changes nothing, but makes a subsequent change where "use warnings" will be added to less confusing and less verbose, since as with "strict" we'll only need to do that at the top of the file. Changes code initially added in a6065b548f (" Try to support ActiveState output pipe", 2006-06-25). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-02-27perl: *.pm files should not have the executable bitÆvar Arnfjörð Bjarmason
The Git::Mail::Address file added in bd869f67b9 ("send-email: add and use a local copy of Mail::Address", 2018-01-05) had the executable bit set. That bit should not be set for *.pm files. It breaks nothing but it is redundant and confusing as none of the other files have it and these files are never executed as stand-alone programs. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-02-23perl: call timegm and timelocal with 4-digit yearBernhard M. Wiedemann
Amazingly, timegm(gmtime(0)) is only 0 before 2020 because perl's timegm deviates from GNU timegm(3) in how it handles years. man Time::Local says Whenever possible, use an absolute four digit year instead. with a detailed explanation about ambiguity of 2-digit years above that. Even though this ambiguity is error-prone with >50% of users getting it wrong, it has been like this for 20+ years, so we just use 4-digit years everywhere to be on the safe side. We add some extra logic to cvsimport because it allows 2-digit year input and interpreting an 18 as 1918 can be avoided easily and safely. Signed-off-by: Bernhard M. Wiedemann <> Signed-off-by: Junio C Hamano <>
2018-02-13Merge branch 'ab/simplify-perl-makefile'Junio C Hamano
The build procedure for perl/ part has been greatly simplified by weaning ourselves off of MakeMaker. * ab/simplify-perl-makefile: perl: treat PERLLIB_EXTRA as an extra path again perl: avoid *.pmc and fix further Makefile: replace perl/Makefile.PL with simple make rules
2018-01-08perl/Git: remove now useless email-address parsing codeMatthieu Moy
We now use Mail::Address unconditionaly, hence parse_mailboxes is now dead code. Remove it and its tests. Signed-off-by: Matthieu Moy <> Reviewed-by: Alex Bennée <> Signed-off-by: Junio C Hamano <>
2018-01-05send-email: add and use a local copy of Mail::AddressMatthieu Moy
We used to have two versions of the email parsing code. Our parse_mailboxes (in, and Mail::Address which we used if installed. Unfortunately, both versions have different sets of bugs, and changing the behavior of git depending on whether Mail::Address is installed was a bad idea. A first attempt to solve this was cc90750 (send-email: don't use Mail::Address, even if available, 2017-08-23), but it turns out our parse_mailboxes is too buggy for some uses. For example the lack of nested comments support breaks in the Linux kernel tree: This patch goes the other way: use Mail::Address anyway, but have a local copy from CPAN as a fallback, when the system one is not available. The duplicated script is small (276 lines of code) and stable in time. Maintaining the local copy should not be an issue, and will certainly be less burden than maintaining our own parse_mailboxes. Another option would be to consider Mail::Address as a hard dependency, but it's easy enough to save the trouble of extra-dependency to the end user or packager. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2017-12-28perl: avoid *.pmc and fix furtherÆvar Arnfjörð Bjarmason
The previous round tried to use *.pmc files but it confused RPM dependency analysis on some distros. Install them as plain vanilla *.pm files instead. Also "local @_" construct did not properly work when goto &sub is used until recent versions of Perl. Avoid it (and we do not need to localize it here anyway). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-12-11Makefile: replace perl/Makefile.PL with simple make rulesÆvar Arnfjörð Bjarmason
Replace the perl/Makefile.PL and the fallback perl/Makefile used under NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily inspired by how the i18n infrastructure's build process works[1]. The reason for having the Makefile.PL in the first place is that it was initially[2] building a perl C binding to interface with libgit, this functionality, that was removed[3] before ever made it to the master branch. We've since since started maintaining a fallback perl/Makefile, as MakeMaker wouldn't work on some platforms[4]. That's just the tip of the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to detect whether we need to regenerate the perl/perl.mak, which I fixed just recently to deal with issues like the perl version changing from under us[6]. There is absolutely no reason for why this needs to be so complex anymore. All we're getting out of this elaborate Rube Goldberg machine was copying perl/* to perl/blib/* as we do a string-replacement on the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as pod2man-ing & friends. So replace the whole thing with something that's pretty much a copy of how we generate po/build/**.mo from po/*.po, just with a small sed(1) command instead of msgfmt. As that's being done rename the files from *.pm to *.pmc just to indicate that they're generated (see "perldoc -f require"). While I'm at it, change the fallback for from being something where we'll ship our own if one doesn't exist at build time to one where we just use a Git::Error wrapper that'll always prefer the system-wide, only falling back to our own copy if it really doesn't exist at runtime. It's now shipped as Git::FromCPAN::Error, making it easy to add other modules to Git::FromCPAN::* in the future if that's needed. Functional changes: * This will not always install into perl's idea of its global "installsitelib". This only potentially matters for packagers that need to expose for non-git use, and as explained in the INSTALL file there's a trivial workaround. * The scripts themselves will 'use lib' the target directory, but if INSTLIBDIR is set it overrides it. It doesn't have to be this way, it could be set in addition to INSTLIBDIR, but my reading of [7] is that this is the desired behavior. * We don't build man pages for all of the perl modules as we used to, only Git(3pm). As discussed on-list[8] that we were building installed manpages for purely internal APIs like Git::I18N or was always a bug anyway, and all the Git::SVN::* ones say they're internal APIs. There are apparently external users of, but I don't expect there to be any of the others. As a side-effect of these general changes the perl documentation now only installed by install-{doc,man}, not a mere "install" as before. 1. 5e9637c629 ("i18n: add infrastructure for translating Git with gettext", 2011-11-18) 2. b1edc53d06 ("Introduce (v4)", 2006-06-24) 3. 18b0fc1ce1 (" Kill Git.xs for now", 2006-09-23) 4. f848718a69 ("Make perl/ build procedure ActiveState friendly.", 2006-12-04) 5. ee9be06770 ("perl: detect new files in MakeMaker builds", 2012-07-27) 6. c59c4939c2 ("perl: regenerate perl.mak if perl -V changes", 2017-03-29) 7. 0386dd37b1 ("Makefile: add PERLLIB_EXTRA variable that adds to default perl path", 2013-11-15) 8. ("Re: [PATCH] Makefile: replace perl/Makefile.PL with simple make rules" Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-11-22Git/ use 'if' instead of 'unless'Christian Couder
The code is more understandable with 'if' instead of 'unless'. Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>