git/perl, branch v2.30.2

Merge branch 'jk/perl-warning'

2020-11-09T22:06:25Z

Dev support. * jk/perl-warning: perl: check for perl warnings while running tests

Merge branch 'bc/svn-hash-oid-fix'

2020-11-02T21:17:45Z

A recent oid->hash conversion missed one spot, breaking "git svn". * bc/svn-hash-oid-fix: svn: use correct variable name for short OID

perl: check for perl warnings while running tests

2020-10-22T06:11:48Z

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 Signed-off-by: Junio C Hamano

svn: use correct variable name for short OID

2020-10-22T06:03:31Z

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 Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

git-send-email: die if sendmail.* config is set

2020-07-24T01:00:34Z

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

perl: make SVN code hash independent

2020-06-22T18:21:07Z

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

perl: make Git::IndexInfo work with SHA-256

2020-06-22T18:21:07Z

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

perl: create and switch variables for hash constants

2020-06-22T18:21:07Z

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

Fix spelling errors in documentation outside of Documentation/

2019-11-07T04:42:00Z

Reported-by: Jens Schleusener Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

git-svn: trim leading and trailing whitespaces in author name

2019-09-28T04:51:42Z

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