git/git-svn.perl, branch jch

Makefile: consistently use @PLACEHOLDER@ to substitute

2024-12-06T22:52:08Z

We have a bunch of placeholders in our scripts that we replace at build time, for example by using sed(1). These placeholders come in three different formats: @PLACEHOLDER@, @@PLACEHOLDER@@ and ++PLACEHOLDER++. Next to being inconsistent it also creates a bit of a problem with CMake, which only supports the first syntax in its `configure_file()` function. To work around that we instead manually replace placeholders via string operations, which is a hassle and removes safeguards that CMake has to verify that we didn't forget to replace any placeholders. Besides that, other build systems like Meson also support the CMake syntax. Unify our codebase to consistently use the syntax supported by such build systems. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Require Perl 5.26.0

2024-10-23T20:16:36Z

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 Signed-off-by: Taylor Blau

git-svn: mention `svn:global-ignores` in help+docs

2024-08-14T22:10:24Z

Git-SVN was previously taught to use the svn:global-ignores property as well as svn:ignore when creating or showing .gitignore files from a Subversion repository. However, the documentation and help message still only mentioned svn:ignore. Update Git-SVN's documentation and help command to mention support for the new property. Also capitalize the help message for the 'mkdirs' command, for consistency. Signed-off-by: Alex Galvin Signed-off-by: Junio C Hamano

git-svn: use `svn:global-ignores` to create .gitignore

2024-07-18T22:48:06Z

`svn:global-ignores` contains a list of file patterns that should not be tracked in version control. The syntax of these patterns is the same as `svn:ignore`. Their semantics differ: patterns in `svn:global-ignores` apply to all paths under the directory where they apply, while `svn:ignore` only applies to the directory's immediate children. Signed-off-by: Alex Galvin Signed-off-by: Junio C Hamano

Merge branch 'tz/send-email-negatable-options'

2023-12-10T00:37:51Z

Newer versions of Getopt::Long started giving warnings against our (ab)use of it in "git send-email". Bump the minimum version requirement for Perl to 5.8.1 (from September 2002) to allow simplifying our implementation. * tz/send-email-negatable-options: send-email: avoid duplicate specification warnings perl: bump the required Perl version to 5.8.1 from 5.8.0

perl: bump the required Perl version to 5.8.1 from 5.8.0

2023-11-16T22:26:32Z

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

git-svn: drop FakeTerm hack

2023-08-31T00:20:31Z

Drop the FakeTerm hack, just like dfd46bae (send-email: drop FakeTerm hack, 2023-08-08) did, for exactly the same reason. It has been obsolete in git-svn since 30d45f798d (git-svn: delay term initialization, 2014-09-14). Note that unlike send-email, we already make sure to load Term::ReadLine only once. So this is just a cleanup, and not fixing any bug. Signed-off-by: Wesley Schwengle Helped-by: Jeff King Signed-off-by: Junio C Hamano

git-svn: drop support for `--preserve-merges`

2021-09-08T04:45:33Z

We already passed the `--rebase-merges` option to `git rebase` instead, now we make this move permanent. As pointed out by Ævar Arnfjörð Bjarmason, in contrast to the deprecation of `git rebase`'s `--preserve-merges` backend, `git svn` only deprecated this option in v2.25.0 (because this developer missed `git svn`'s use of that backend when deprecating the rebase backend running up to Git v2.22). Still, v2.25.0 has been released on January 13th, 2020. In other words, `git svn` deprecated this option over one and a half years ago, _and_ has been redirecting to the `--rebase-merges` option during all that time (read: `git svn rebase --preserve-merges` didn't do _precisely_ what the user asked, since v2.25.0, anyway, it fell back to pretending that the user asked for `git svn rebase --rebase-merges` instead). It is time to act on that deprecation and remove that option after all. Signed-off-by: Johannes Schindelin Reviewed-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

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

git-svn: set the OID length based on hash algorithm

2020-06-22T18:21:07Z

When reading the configuration or when creating a new repository, load the extensions.objectFormat value and set the object ID length to 64 if it's "sha256". Note that we use the hex length in git-svn because most of our processing is done on hex values, not binary ones. Signed-off-by: brian m. carlson Acked-by: Eric Wong Signed-off-by: Junio C Hamano