summaryrefslogtreecommitdiff
path: root/perl
AgeCommit message (Collapse)AuthorFilesLines
2021-05-27Merge branch 'ab/send-email-inline-hooks-path'Libravatar Junio C Hamano1-13/+0
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.perlLibravatar Ævar Arnfjörð Bjarmason1-12/+0
Move the newly added "hooks_path" API in Git.pm 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 Git.pm 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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27send-email: don't needlessly abs_path() the core.hooksPathLibravatar Ævar Arnfjörð Bjarmason1-2/+1
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 (t9001-send-email.sh: 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. http://lore.kernel.org/git/bb30fe2b-cd75-4782-24a6-08bb002a0367@kdbg.org Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-06perl: use mock i18n functions under NO_GETTEXT=YLibravatar Ævar Arnfjörð Bjarmason1-0/+10
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 POSIX.pm is around 20ms on my machine, whereas it takes 2ms to just instantiate perl itself. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-23git-send-email: Respect core.hooksPath settingLibravatar Robert Foss1-0/+13
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 <robert.foss@linaro.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-09Merge branch 'jk/perl-warning'Libravatar Junio C Hamano18-18/+18
Dev support. * jk/perl-warning: perl: check for perl warnings while running tests
2020-11-02Merge branch 'bc/svn-hash-oid-fix'Libravatar Junio C Hamano1-1/+1
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-21perl: check for perl warnings while running testsLibravatar Jeff King18-18/+18
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 test-lib.sh 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-21svn: use correct variable name for short OIDLibravatar brian m. carlson1-1/+1
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/Log.pm 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 <realnc@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-23git-send-email: die if sendmail.* config is setLibravatar Drew DeVault1-0/+26
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 <sir@cmpwn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22perl: make SVN code hash independentLibravatar brian m. carlson4-43/+46
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 <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22perl: make Git::IndexInfo work with SHA-256Libravatar brian m. carlson1-2/+4
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 <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22perl: create and switch variables for hash constantsLibravatar brian m. carlson3-7/+7
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 <sandals@crustytoothpaste.net> Acked-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-07Fix spelling errors in documentation outside of Documentation/Libravatar Elijah Newren1-1/+1
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-28git-svn: trim leading and trailing whitespaces in author nameLibravatar Tobias Klauser1-0/+4
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 <user1@example.com> Fix this by trimming the author name retreived from svn before using it in check_author. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-01Git.pm: make hash size independentLibravatar brian m. carlson1-1/+1
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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-08Merge branch 'ab/git-svn-get-record-typofix'Libravatar Junio C Hamano1-1/+1
"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'Libravatar Junio C Hamano3-1/+44
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 supportLibravatar Dan Jacques2-1/+43
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 <dnj@google.com> Thanks-to: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Thanks-to: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11Makefile: generate Perl header from template fileLibravatar Dan Jacques1-0/+1
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 <dnj@google.com> Thanks-to: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Thanks-to: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09git-svn: avoid warning on undef readline()Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Change code in Git.pm 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 Git.pm in my f0e19cb7ce ("Git.pm: 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 https://public-inbox.org/git/86h8oobl36.fsf@phe.ftfl.ca/ for the original report. Reported-by: Joseph Mingrone <jrm@ftfl.ca> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Improved-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-05git-svn: allow empty email-address using authors-prog and authors-fileLibravatar Andreas Heiduk1-7/+6
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 <asheiduk@gmail.com> Signed-off-by: Eric Wong <e@80x24.org>
2018-03-15Merge branch 'ab/perl-fixes'Libravatar Junio C Hamano9-123/+389
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 Error.pm git-send-email: unconditionally use Net::{SMTP,Domain} Git.pm: hard-depend on the File::{Temp,Spec} modules gitweb: hard-depend on the Digest::MD5 5.8 module Git.pm: add the "use warnings" pragma Git.pm: 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'Libravatar Junio C Hamano2-2/+4
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_FALLBACKSLibravatar Ævar Arnfjörð Bjarmason1-1/+32
Before my 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple make rules", 2017-12-10) on an OS package that removed the private-Error.pm copy we carried around manually removing the OS's Error.pm would yield: $ git add -p Can't locate Error.pm 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/Error.pm 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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05perl: move the perl/Git/FromCPAN tree to perl/FromCPANLibravatar Ævar Arnfjörð Bjarmason4-3/+2
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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05perl: generalize the Git::LoadCPAN facilityLibravatar Ævar Arnfjörð Bjarmason3-58/+82
Change the two wrappers that load from CPAN (local OS) or our own copy to do so via the same codepath. I added the Error.pm 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 Error.pm 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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05perl: move CPAN loader wrappers to another namespaceLibravatar Ævar Arnfjörð Bjarmason3-7/+7
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 ("Git.pm: Handle failed commands' output", 2006-06-24). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05perl: update our copy of Mail::AddressLibravatar Ævar Arnfjörð Bjarmason1-2/+6
Update our copy of Mail::Address from 2.19 (Aug 22, 2017) to 2.20 (Jan 23, 2018). Like the preceding Error.pm 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 https://fastapi.metacpan.org/source/MARKOV/MailTools-2.20/lib/Mail/Address.pm Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05perl: update our ancient copy of Error.pmLibravatar Ævar Arnfjörð Bjarmason2-41/+255
The Error.pm shipped with Git as a fallback if there was no Error.pm 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 Error.pm, 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 private-Error.pm", 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 https://fastapi.metacpan.org/source/SHLOMIF/Error-0.17025/lib/Error.pm Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05Git.pm: hard-depend on the File::{Temp,Spec} modulesLibravatar Ævar Arnfjörð Bjarmason1-8/+2
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 ("Git.pm: Make File::Spec and File::Temp requirement lazy", 2008-08-15), presumably to make Git.pm work on 5.6.0. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-27Git.pm: add the "use warnings" pragmaLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Amend Git.pm 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 Git.pm (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/Mediawiki.pm 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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-27Git.pm: remove redundant "use strict" from sub-packageLibravatar Ævar Arnfjörð Bjarmason1-1/+0
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 Git.pm 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 ("Git.pm: Try to support ActiveState output pipe", 2006-06-25). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-27perl: *.pm files should not have the executable bitLibravatar Ævar Arnfjörð Bjarmason1-0/+0
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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-23perl: call timegm and timelocal with 4-digit yearLibravatar Bernhard M. Wiedemann2-2/+4
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 <bwiedemann@suse.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-13Merge branch 'ab/simplify-perl-makefile'Libravatar Junio C Hamano7-162/+49
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 Error.pm further Makefile: replace perl/Makefile.PL with simple make rules
2018-01-08perl/Git: remove now useless email-address parsing codeLibravatar Matthieu Moy1-71/+0
We now use Mail::Address unconditionaly, hence parse_mailboxes is now dead code. Remove it and its tests. Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05send-email: add and use a local copy of Mail::AddressLibravatar Matthieu Moy2-0/+300
We used to have two versions of the email parsing code. Our parse_mailboxes (in Git.pm), 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 get_maintainer.pl in the Linux kernel tree: https://public-inbox.org/git/20171116154814.23785-1-alex.bennee@linaro.org/ 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 <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-28perl: avoid *.pmc and fix Error.pm furtherLibravatar Ævar Arnfjörð Bjarmason1-1/+1
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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11Makefile: replace perl/Makefile.PL with simple make rulesLibravatar Ævar Arnfjörð Bjarmason7-162/+49
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 Git.pm 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 Git.pm & 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 Error.pm from being something where we'll ship our own Error.pm 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 Error.pm, 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 Git.pm 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 private-Error.pm was always a bug anyway, and all the Git::SVN::* ones say they're internal APIs. There are apparently external users of Git.pm, 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 Git.pm (v4)", 2006-06-24) 3. 18b0fc1ce1 ("Git.pm: 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. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile: replace perl/Makefile.PL with simple make rules" Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22Git/Packet.pm: use 'if' instead of 'unless'Libravatar Christian Couder1-8/+8
The code is more understandable with 'if' instead of 'unless'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22Git/Packet: clarify that packet_required_key_val_read allows EOFLibravatar Christian Couder1-2/+7
The function calls itself "required", but it does not die when it sees an unexpected EOF. Let's rename it to "packet_key_val_read()". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-07Git/Packet.pm: extract parts of t0021/rot13-filter.pl for reuseLibravatar Christian Couder2-0/+169
And while at it let's simplify t0021/rot13-filter.pl by using Git/Packet.pm. This will make it possible to reuse packet related functions in other test scripts. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22Merge branch 'ur/svn-local-zone'Libravatar Junio C Hamano1-1/+1
"git svn" used with "--localtime" option did not compute the tz offset for the timestamp in question and instead always used the current time, which has been corrected. * ur/svn-local-zone: git svn fetch: Create correct commit timestamp when using --localtime
2017-08-22Merge branch 'jc/perl-git-comment-typofix'Libravatar Junio C Hamano1-1/+1
A comment fix. * jc/perl-git-comment-typofix: perl/Git.pm: typofix in a comment
2017-08-08git svn fetch: Create correct commit timestamp when using --localtimeLibravatar Urs Thuermann1-1/+1
In parse_svn_date() prepend the correct UTC offset to the timestamp returned. This is the offset in effect at the commit time instead of the offset in effect at calling time. Signed-off-by: Urs Thuermann <urs@isnogud.escape.de> Reviewed-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-07perl/Git.pm: typofix in a commentLibravatar Junio C Hamano1-1/+1
No change of behaviour intended. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-10Merge branch 'pw/unquote-path-in-git-pm'Libravatar Junio C Hamano1-1/+53
Code refactoring. * pw/unquote-path-in-git-pm: t9700: add tests for Git::unquote_path() Git::unquote_path(): throw an exception on bad path Git::unquote_path(): handle '\a' add -i: move unquote_path() to Git.pm
2017-06-30Git::unquote_path(): throw an exception on bad pathLibravatar Phillip Wood1-2/+2
This is what the other routines in Git.pm do if there's an error. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-30Git::unquote_path(): handle '\a'Libravatar Phillip Wood1-1/+2
unquote_path() does not handle quoted paths containing '\a', even though quote.c::unquote_c_style() does, and quote.c:sq_lookup[] tells quote.c::sq_must_quote() that '\007' must be quoted as '\a'. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>