summaryrefslogtreecommitdiff
path: root/perl/Git
AgeCommit message (Collapse)AuthorFilesLines
2020-11-09Merge branch 'jk/perl-warning'Libravatar Junio C Hamano16-16/+16
Dev support. * jk/perl-warning: perl: check for perl warnings while running tests
2020-10-21perl: check for perl warnings while running testsLibravatar Jeff King16-16/+16
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-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-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>
2018-05-08Merge branch 'dj/runtime-prefix'Libravatar Junio C Hamano1-1/+1
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 Jacques1-1/+1
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-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 Hamano7-1173/+124
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 Hamano1-1/+1
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-1324/+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ð Bjarmason2-6/+6
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-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. Wiedemann1-1/+1
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 Hamano3-1/+874
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-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ð Bjarmason3-1/+874
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 Couder1-0/+168
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-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-06-27Spelling fixesLibravatar Ville Skyttä1-1/+1
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20Merge branch 'svn-escape-backslash' of git://bogomips.org/git-svnLibravatar Junio C Hamano1-1/+1
* 'svn-escape-backslash' of git://bogomips.org/git-svn: git-svn: escape backslashes in refnames
2016-12-27Merge branch 'va/i18n-perl-scripts'Libravatar Junio C Hamano1-1/+18
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-23git-svn: escape backslashes in refnamesLibravatar Eric Wong1-1/+1
This brings git-svn refname escaping up-to-date with commit a4c2e69936df8dd0b071b85664c6cc6a4870dd84 ("Disallow '\' in ref names") from May 2009. Reported-by: Michael Fladischer <michael@fladi.at> Message-ID: <cb8cd9b1-9882-64d2-435d-40d0b2b82d59@fladi.at> Signed-off-by: Eric Wong <e@80x24.org>
2016-12-14i18n: add--interactive: mark patch prompt for translationLibravatar Vasco Almeida1-1/+10
Mark prompt message assembled in place for translation, unfolding each use case for each entry in the %patch_modes hash table. Previously, this script relied on whether $patch_mode was set to run the command patch_update_cmd() or show status and loop the main loop. Now, it uses $cmd to indicate we must run patch_update_cmd() and $patch_mode is used to tell which flavor of the %patch_modes are we on. This is introduced in order to be able to mark and unfold the message prompt knowing in which context we are. The tracking of context was done previously by point %patch_mode_flavour hash table to the correct entry of %patch_modes, focusing only on value of %patch_modes. Now, we are also interested in the key ('staged', 'stash', 'checkout_head', ...). Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14i18n: add--interactive: mark plural stringsLibravatar Vasco Almeida1-1/+9
Mark plural strings for translation. Unfold each action case in one entire sentence. Pass new keyword for xgettext to extract. Update test to include new subroutine __n() for plural strings handling. Update documentation to include a description of the new __n() subroutine. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-12git-svn: allow "0" in SVN path componentsLibravatar Eric Wong1-1/+1
Blindly checking a path component for falsiness is unwise, as "0" is false to Perl, but a valid pathname component for SVN (or any filesystem). Found via random code reading. Signed-off-by: Eric Wong <e@80x24.org>
2016-10-27Merge branch 'svn-cache' of git://bogomips.org/git-svnLibravatar Junio C Hamano1-1/+11
* 'svn-cache' of git://bogomips.org/git-svn: git-svn: do not reuse caches memoized for a different architecture
2016-10-27git-svn: do not reuse caches memoized for a different architectureLibravatar Gavin Lambert1-1/+11
Reusing cached data speeds up git-svn by quite a fair bit. However, if the YAML module is unavailable, the caches are written to disk in an architecture-dependent manner. That leads to problems when upgrading, say, from 32-bit to 64-bit Git for Windows. Let's just try to read those caches back if we detect the absence of the YAML module and the presence of the file, and delete the file if it could not be read back correctly. Note that the only way to catch the error when the memoized cache could not be read back is to put the call inside an `eval { ... }` block because it would die otherwise; the `eval` block should also return `1` in case of success explicitly since the function reading back the cached data does not return an appropriate value to test for success. This fixes https://github.com/git-for-windows/git/issues/233. [ew: import "retrieve" explictly, check unlink result] Signed-off-by: Gavin Lambert <github@mirality.co.nz> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Eric Wong <e@80x24.org>
2016-10-14git-svn: "git worktree" awarenessLibravatar Eric Wong2-24/+37
git-svn internals were previously not aware of repository layout differences for users of the "git worktree" command. Introduce this awareness by using "git rev-parse --git-path" instead of relying on outdated uses of GIT_DIR and friends. Thanks-to: Duy Nguyen <pclouds@gmail.com> Reported-by: Mathieu Arnold <mat@freebsd.org> Signed-off-by: Eric Wong <e@80x24.org>
2016-10-14git-svn: reduce scope of input record separator changeLibravatar Eric Wong2-17/+10
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-07-09git-svn: warn instead of dying when commit data is missingLibravatar Eric Wong1-2/+6
It is possible to have refs globbed by git-svn which stores data purely in git; gently skip those instead of dying and assuming user error. ref: http://mid.gmane.org/CALi1mtdtNF_GtzyPTbfb7N51wwxsFY7zm8hsgwxr3tHcZZboyg@mail.gmail.com Suggested-by: Jacob Godserv <jacobgodserv@gmail.com> Cc: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-22git-svn: skip mergeinfo handling with --no-follow-parentLibravatar Eric Wong1-9/+16
For repositories without parent following enabled, finding git parents through svn:mergeinfo or svk::parents can be expensive and pointless. Reported-by: Александр Овчинников <proff@proff.email> http://mid.gmane.org/4094761466408188@web24o.yandex.ru Signed-off-by: Eric Wong <e@80x24.org>
2016-05-08Git/SVN: die when there is no commit metadataLibravatar Christian Couder1-1/+2
When passing a bad --trunk option to `git svn clone`, like for example the same URL that we are cloning: C:\Windows\system32>git svn clone https://mycompany.svn.beanstalkapp.com/myproject --no-metadata -A c:\temp\svn_to_git_users.txt --trunk=https://mycompany.svn.beanstalkapp.com/myproject --tags=https://mycompany.svn.beanstalkapp.com/myproject/tags --branches=https://mycompany.svn.beanstalkapp.com/myproject/branches c:\code\Git_myproject One gets an "Use of uninitialized value $u in substitution (s///)" error: [...] W: +empty_dir: branches/20080918_DBDEPLOY/vendor/src/csharp/MS WCSF Contrib/src/Services W: +empty_dir: branches/20080918_DBDEPLOY/vendor/src/csharp/RealWorldControls/References r530 = c276e3b039d8e38759c6fb17443349732552d7a2 (refs/remotes/origin/trunk) Found possible branch point: https://mycompany.svn.beanstalkapp.com/myproject/trunk => https://mycompany.svn.beanstalkapp.com/myproject/branches/20080918_DBDEPLOY, 529 Use of uninitialized value $u in substitution (s///) at /mingw32/share/perl5/site_perl/Git/SVN.pm line 101. Use of uninitialized value $u in concatenation (.) or string at /mingw32/share/perl5/site_perl/Git/SVN.pm line 101. refs/remotes/origin/trunk: 'https://mycompany.svn.beanstalkapp.com/myproject' not found in '' C:\Windows\system32> Let's fix that by just die()ing when we have an uninitialized value because we cannot get commit metadata from a ref. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Eric Wong <e@80x24.org>
2016-03-15git-svn: shorten glob error messageLibravatar Eric Wong1-2/+2
Error messages should attempt to fit within the confines of an 80-column terminal to avoid compatibility and accessibility problems. Furthermore the word "directories" can be misleading when used in the context of git refnames. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2016-03-15git-svn: loosen config globs limitationsLibravatar Victor Leschuk1-5/+9
Expand the area of globs applicability for branches and tags in git-svn. It is now possible to use globs like 'a*e', or 'release_*'. This allows users to avoid long lines in config like: branches = branches/{release_20,release_21,release_22,...} In favor of: branches = branches/release_* [ew: amended commit message, minor formatting and style fixes] Signed-off-by: Victor Leschuk <vleschuk@accesssoftek.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2016-02-22git-svn: apply "svn.pathnameencoding" before URL encodingLibravatar Kazutoshi Satoda1-1/+2
The conversion from "svn.pathnameencoding" to UTF-8 should be applied first, and then URL encoding should be applied on the resulting UTF-8 path. The reversed order of these transforms (used before this fix) makes non-UTF-8 URL which causes error from Subversion such as "Filesystem has no item: '...' path not found" when sending a rename (or a copy) from non-ASCII path. [ew: t9115 test case added (requires SVN_HTTPD_PORT set to test), squash LC_ALL=$a_utf8_locale export from Kazutoshi for Cygwin] Signed-off-by: Kazutoshi SATODA <k_satoda@f2.dion.ne.jp> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2016-02-22git-svn: enable "svn.pathnameencoding" on dcommitLibravatar Kazutoshi Satoda1-0/+1
Without the initialization of $self->{pathnameencoding}, conversion in repo_path() is always skipped as $self->{pathnameencoding} is undefined even if "svn.pathnameencoding" is configured. The lack of conversion results in mysterious failure of dcommit (e.g. "Malformed XML") which happen only when a commit involves a change on non-ASCII path. [ew: add test case to t9115, squash LC_ALL=$a_utf8_locale export from Kazutoshi for Cygwin] Signed-off-by: Kazutoshi SATODA <k_satoda@f2.dion.ne.jp> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2016-02-01Merge branch 'ew/svn-1.9.0-auth'Libravatar Junio C Hamano1-2/+6
* ew/svn-1.9.0-auth: git-svn: fix auth parameter handling on SVN 1.9.0+
2016-01-26git-svn: fix auth parameter handling on SVN 1.9.0+Libravatar Eric Wong1-2/+6
For users with "store-passwords = no" set in the "[auth]" section of their ~/.subversion/config, SVN 1.9.0+ would fail with the following message when attempting to call svn_auth_set_parameter: Value is not a string (or undef) at Git/SVN/Ra.pm Ironically, this breakage was caused by r1553823 in subversion: "Make svn_auth_set_parameter() usable from Perl bindings." Since 2007 (602015e0e6ec), git-svn has used a workaround to make svn_auth_set_parameter usable internally. However this workaround breaks under SVN 1.9+, which deals properly with the type mapping and fails to recognize our workaround. For pre-1.9.0 SVN, we continue to use the existing workaround for the lack of proper type mapping in the bindings. Tested under subversion 1.6.17 and 1.9.3. I've also verified r1553823 was not backported to SVN 1.8.x: BRANCH=http://svn.apache.org/repos/asf/subversion/branches/1.8.x svn log -v $BRANCH/subversion/bindings/swig/core.i ref: https://bugs.debian.org/797705 Cc: 797705@bugs.debian.org Reported-by: Thierry Vignaud <thierry.vignaud@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Tested-by: Thierry Vignaud <thierry.vignaud@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-10git-svn: improve rebase/mkdirs performanceLibravatar Dair Grant1-8/+76
Processing empty_dir directives becomes extremely slow for svn repositories with a large enough history. This is due to using a single hash to store the list of empty directories, with the expensive step being purging items from that hash using grep+delete. Storing directories in a hash of hashes improves the performance of this purge step and removes a potentially lengthy delay after every rebase/mkdirs command. The svn repository with this behaviour has 110K commits with unhandled.log containing 170K empty_dir directives. This takes 10 minutes to process when using a single hash, vs 3 seconds with a hash of hashes. Signed-off-by: Dair Grant <dair@feralinteractive.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>