summaryrefslogtreecommitdiff
path: root/perl/Git.pm
AgeCommit message (Collapse)Author
2025-06-25contrib: better support symbolic port names in git-credential-netrcMaxim Cournoyer
To improve support for symbolic port names in netrc files, this changes does the following: - Treat symbolic port names as ports, not protocols in git-credential-netrc - Validate the SMTP server port provided to send-email - Convert the above symbolic port names to their numerical values. Before this change, it was not possible to have a SMTP server port set to "smtps" in a netrc file (e.g. Emacs' ~/.authinfo.gpg), as it would be registered as a protocol and break the match for a "smtp" protocol host, as queried for by git-send-email. Signed-off-by: Maxim Cournoyer <maxim@guixotic.coop> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-23Require Perl 5.26.0brian m. carlson
Our platform support policy states that we require "versions of dependencies which are generally accepted as stable and supportable, e.g., in line with the version used by other long-term-support distributions". Of Debian, Ubuntu, RHEL, and SLES, the four most common distributions that provide LTS versions, the version with mainstream long-term security support with the oldest Perl is 5.26.0 in SLES 15.6. This is a major upgrade, since Perl 5.8.1, according to the Perl documentation, was released in September of 2003. It brings a lot of new features that we can choose to use, such as s///r to return the modified string, the postderef functionality, and subroutine signatures, although the latter was still considered experimental until 5.36. This change was made with the following one-liner, which intentionally excludes modifying the vendored modules we include to avoid conflicts: git grep -l 'use 5.008001' | grep -v 'LoadCPAN/' | xargs perl -pi -e 's/use 5.008001/require v5.26/' Use require instead of use to avoid changing the behavior as the latter enables features and the former does not. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Taylor Blau <me@ttaylorr.com>
2024-09-20Merge branch 'jk/git-pm-bare-repo-fix'Junio C Hamano
In Git 2.39, Git.pm stopped working in a bare repository, which has been corrected. * jk/git-pm-bare-repo-fix: Git.pm: use "rev-parse --absolute-git-dir" rather than perl code Git.pm: fix bare repository search with Directory option
2024-09-13Git.pm: use "rev-parse --absolute-git-dir" rather than perl codeJeff King
When we open a repository with the "Directory" option, we use "rev-parse --git-dir" to get the path relative to that directory, and then use Cwd::abs_path() to make it absolute (since our process working directory may not be the same). These days we can just ask for "--absolute-git-dir" instead, which saves us a little code. That option was added in Git v2.13.0 via a2f5a87626 (rev-parse: add '--absolute-git-dir' option, 2017-02-03). I don't think we make any promises about running mismatched versions of git and Git.pm, but even if somebody tries it, that's sufficiently old that it should be OK. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-13Git.pm: fix bare repository search with Directory optionJeff King
When opening a bare repository like: Git->repository(Directory => '/path/to/bare.git'); we will incorrectly point the repository object at the _current_ directory, not the one specified by the option. The bug was introduced by 20da61f25f (Git.pm: trust rev-parse to find bare repositories, 2022-10-22). Before then, we'd ask "rev-parse --git-dir" if it was a Git repo, and if it returned anything, we'd correctly convert that result to an absolute path using File::Spec and Cwd::abs_path(). If it didn't, we'd guess it might be a bare repository and find it ourselves, which was wrong (rev-parse should find even a bare repo, and our search circumvented some of its rules). That commit dropped most of the custom bare-repo search code in favor of using "rev-parse --is-bare-repository" and trusting the "--git-dir" it returned. But it mistakenly left some of the bare-repo code path in place, which was now broken. That code calls Cwd::abs_path($dir); prior to 20da61f25f $dir contained the "Directory" option the user passed in. But afterwards, it contains the output of "rev-parse --git-dir". And since our tentative rev-parse command is invoked after changing directory, it will always be the relative path "."! So we'll end up with the absolute path of the process's current directory, not the Directory option the caller asked for. So the non-bare case is correct, but the bare one is broken. Our tests only check the non-bare one, so we didn't notice. We can fix this by running the same absolute-path fixup code for both sides. Helped-by: Rodrigo <rodrigolive@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-17Git.pm: use array in command_bidi_pipe exampleEric Wong
command_bidi_pipe takes the git command and optional arguments as an array, not a string. Make sure the documentation example is usable code. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-11-17perl: bump the required Perl version to 5.8.1 from 5.8.0Todd Zullinger
The following commit will make use of a Getopt::Long feature which is only present in Perl >= 5.8.1. Document that as the minimum version we support. Many of our Perl scripts will continue to run with 5.8.0 but this change allows us to adjust them as needed without breaking any promises to our users. The Perl requirement was last changed in d48b284183 (perl: bump the required Perl version to 5.8 from 5.6.[21], 2010-09-24). At that time, 5.8.0 was 8 years old. It is now over 21 years old. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-22Git.pm: 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 (Git.pm: 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 Git.pm'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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-17Git.pm: 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 Error.pm'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] https://lore.kernel.org/git/20221011182607.f1113fff-9333-427d-ba45-741a78fa6040@korelogic.com/ Reported-by: Hank Leininger <hlein@korelogic.com> Signed-off-by: Michael McClimon <michael@mcclimon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-01perl Git.pm: don't ignore signalled failure in _cmd_close()Ævar Arnfjörð Bjarmason
Fix misbehavior in Git.pm that dates back to the very first version of the library in git.git added in b1edc53d062 (Introduce Git.pm (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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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. https://lore.kernel.org/git/20210512180517.GA11354@dcvr/ 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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28perl: lazily load some common Git.pm 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 Git.pm 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 t9001-send-email.sh test is down to ~13s from ~15s. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 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.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 (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-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 <robert.foss@linaro.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-21perl: 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 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-07-23git-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 <sir@cmpwn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-07Fix spelling errors in documentation outside of Documentation/Elijah Newren
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-04-01Git.pm: 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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-04-09git-svn: avoid warning on undef readline()Ævar Arnfjörð Bjarmason
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-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 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'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: 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 ("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-05Git.pm: 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 ("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" pragmaÆvar Arnfjörð Bjarmason
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-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 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-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 <bwiedemann@suse.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 Error.pm 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 <git@matthieu-moy.fr> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 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-08-22Merge branch 'jc/perl-git-comment-typofix'Junio C Hamano
A comment fix. * jc/perl-git-comment-typofix: perl/Git.pm: typofix in a comment
2017-08-07perl/Git.pm: typofix in a commentJunio C Hamano
No change of behaviour intended. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-30Git::unquote_path(): throw an exception on bad pathPhillip Wood
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'Phillip Wood
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>
2017-06-30add -i: move unquote_path() to Git.pmPhillip Wood
Move unquote_path() from git-add--interactive to Git.pm so it can be used by other scripts. Note this is a straight copy, it does not handle '\a'. That will be fixed in the next commit. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-27Merge branch 'va/i18n-perl-scripts'Junio C Hamano
Porcelain scripts written in Perl are getting internationalized. * va/i18n-perl-scripts: i18n: difftool: mark warnings for translation i18n: send-email: mark composing message for translation i18n: send-email: mark string with interpolation for translation i18n: send-email: mark warnings and errors for translation i18n: send-email: mark strings for translation i18n: add--interactive: mark status words for translation i18n: add--interactive: remove %patch_modes entries i18n: add--interactive: mark edit_hunk_manually message for translation i18n: add--interactive: i18n of help_patch_cmd i18n: add--interactive: mark patch prompt for translation i18n: add--interactive: mark plural strings i18n: clean.c: match string with git-add--interactive.perl i18n: add--interactive: mark strings with interpolation for translation i18n: add--interactive: mark simple here-documents for translation i18n: add--interactive: mark strings for translation Git.pm: add subroutines for commenting lines
2016-12-14Git.pm: add subroutines for commenting linesVasco Almeida
Add subroutines prefix_lines and comment_lines. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-29Merge branch 'mm/send-email-cc-cruft-after-address' into maintJunio C Hamano
"git send-email" attempts to pick up valid e-mails from the trailers, but people in real world write non-addresses there, like "Cc: Stable <add@re.ss> # 4.8+", which broke the output depending on the availability and vintage of Mail::Address perl module. * mm/send-email-cc-cruft-after-address: Git.pm: add comment pointing to t9000 t9000-addresses: update expected results after fix parse_mailboxes: accept extra text after <...> address
2016-10-27Merge branch 'svn-wt' of git://bogomips.org/git-svnJunio C Hamano
* 'svn-wt' of git://bogomips.org/git-svn: git-svn: "git worktree" awareness git-svn: reduce scope of input record separator change
2016-10-26Merge branch 'mm/send-email-cc-cruft-after-address'Junio C Hamano
"git send-email" attempts to pick up valid e-mails from the trailers, but people in real world write non-addresses there, like "Cc: Stable <add@re.ss> # 4.8+", which broke the output depending on the availability and vintage of Mail::Address perl module. * mm/send-email-cc-cruft-after-address: Git.pm: add comment pointing to t9000 t9000-addresses: update expected results after fix parse_mailboxes: accept extra text after <...> address
2016-10-21Git.pm: add comment pointing to t9000Matthieu Moy
parse_mailboxes should probably eventually be completely equivalent to Mail::Address, and if this happens we can drop the Mail::Address dependency. Add a comment in the code reminding the current state of the code, and point to the corresponding failing test to help future contributors to get it right. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-14parse_mailboxes: accept extra text after <...> addressMatthieu Moy
The test introduced in this commit succeeds without the patch to Git.pm if Mail::Address is installed, but fails otherwise because our in-house parser does not accept any text after the email address. They succeed both with and without Mail::Address after this commit. Mail::Address accepts extra text and considers it as part of the name, iff the address is surrounded with <...>. The implementation mimics this behavior as closely as possible. This mostly restores the behavior we had before b1c8a11 (send-email: allow multiple emails using --cc, --to and --bcc, 2015-06-30), but we keep the possibility to handle comma-separated lists. Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-14git-svn: reduce scope of input record separator changeEric Wong
Reducing the scope of where we change the record separator ($/) avoids bugs in calls which rely on the input record separator further down, such as the 'chomp' usage in command_oneline. This is necessary for a future change to git-svn, but exists in Git.pm since it seems useful for gitweb and our other Perl scripts, too. Signed-off-by: Eric Wong <e@80x24.org>
2016-05-06typofix: assorted typofixes in comments, documentation and messagesLi Peng
Many instances of duplicate words (e.g. "the the path") and a few typoes are fixed, originally in multiple patches. wildmatch: fix duplicate words of "the" t: fix duplicate words of "output" transport-helper: fix duplicate words of "read" Git.pm: fix duplicate words of "return" path: fix duplicate words of "look" pack-protocol.txt: fix duplicate words of "the" precompose-utf8: fix typo of "sequences" split-index: fix typo worktree.c: fix typo remote-ext: fix typo utf8: fix duplicate words of "the" git-cvsserver: fix duplicate words Signed-off-by: Li Peng <lip@dtdream.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26Git.pm: stop assuming that absolute paths start with a slashJohannes Schindelin
On Windows, absolute paths never start with a slash, unless a POSIX emulation layer is used. The latter is the case for MSYS2's Perl that Git for Windows leverages. However, in the tests we also go through plain `git.exe`, which does *not* leverage the POSIX emulation layer, and therefore the paths we pass to Perl may actually be DOS-style paths such as C:/Program Files/Git. So let's just use Perl's own way to test whether a given path is absolute or not instead of home-brewing our own. This patch partially fixes t7800 and t9700 when running in Git for Windows' SDK. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07send-email: reduce dependencies impact on parse_address_lineRemi Lespinet
parse_address_line had not the same behavior whether the user had Mail::Address or not. Teach parse_address_line to behave like Mail::Address. When the user input is correct, this implementation behaves exactly like Mail::Address except when there are quotes inside the name: "Jane Do"e <jdoe@example.com> In this case the result of parse_address_line is: With M::A : "Jane Do" e <jdoe@example.com> Without : "Jane Do e" <jdoe@example.com> When the user input is not correct, the behavior is also mostly the same. Unlike Mail::Address, this doesn't parse groups and recursive commentaries. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-18Git.pm: two minor typo fixesAlexander Kuleshov
Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-29Git.pm: add specified name to tempfile templateEric Wong
This should help me track down errors in git-svn more easily: write .git/Git_XXXXXX: Bad file descriptor at /usr/lib/perl5/SVN/Ra.pm line 623 Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-07-18Git.pm: revert _temp_cache use of temp_is_lockedKyle J. McKay
When the temp_is_locked function was introduced, there was a desire to make _temp_cache use it. Unfortunately due to the various tests and logic flow involved changing the _temp_cache function to use the new temp_is_locked function is problematic as _temp_cache needs a slightly different test than is provided by the temp_is_locked function. This change reverts use of temp_is_locked in the _temp_cache function and restores the original code that existed there before the temp_is_locked function was added. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>