From 9e382c09ad0c1cadad381919234c11213fbef4bb Mon Sep 17 00:00:00 2001 From: "Enrico Weigelt, metux IT consult" Date: Mon, 9 Feb 2026 16:24:16 +0100 Subject: [PATCH 1/2] apply WD-40 in order to maintain platform / cpu-arch compatibility Signed-off-by: Enrico Weigelt, metux IT consult --- .github/workflows/main.yml | 15 --- .gitignore | 2 - .gitlab-ci.yml | 13 +-- Cargo.toml | 10 -- Documentation/BreakingChanges.adoc | 45 --------- Documentation/technical/build-systems.adoc | 6 -- Makefile | 92 ------------------ README.md | 2 + ci/install-dependencies.sh | 11 --- ci/run-build-and-tests.sh | 2 +- ci/run-rust-checks.sh | 22 ----- contrib/libgit-rs/Cargo.lock | 77 --------------- contrib/libgit-rs/Cargo.toml | 17 ---- contrib/libgit-rs/README.md | 13 --- contrib/libgit-rs/build.rs | 4 - contrib/libgit-rs/src/config.rs | 106 -------------------- contrib/libgit-rs/src/lib.rs | 1 - contrib/libgit-rs/testdata/config1 | 2 - contrib/libgit-rs/testdata/config2 | 2 - contrib/libgit-rs/testdata/config3 | 2 - contrib/libgit-sys/Cargo.lock | 69 ------------- contrib/libgit-sys/Cargo.toml | 19 ---- contrib/libgit-sys/README.md | 4 - contrib/libgit-sys/build.rs | 35 ------- contrib/libgit-sys/public_symbol_export.c | 59 ------------ contrib/libgit-sys/public_symbol_export.h | 18 ---- contrib/libgit-sys/src/lib.rs | 79 --------------- help.c | 7 +- meson.build | 15 +-- src/cargo-meson.sh | 39 -------- src/lib.rs | 1 - src/meson.build | 41 -------- src/varint.rs | 107 --------------------- t/Makefile | 3 - 34 files changed, 7 insertions(+), 933 deletions(-) delete mode 100644 Cargo.toml delete mode 100755 ci/run-rust-checks.sh delete mode 100644 contrib/libgit-rs/Cargo.lock delete mode 100644 contrib/libgit-rs/Cargo.toml delete mode 100644 contrib/libgit-rs/README.md delete mode 100644 contrib/libgit-rs/build.rs delete mode 100644 contrib/libgit-rs/src/config.rs delete mode 100644 contrib/libgit-rs/src/lib.rs delete mode 100644 contrib/libgit-rs/testdata/config1 delete mode 100644 contrib/libgit-rs/testdata/config2 delete mode 100644 contrib/libgit-rs/testdata/config3 delete mode 100644 contrib/libgit-sys/Cargo.lock delete mode 100644 contrib/libgit-sys/Cargo.toml delete mode 100644 contrib/libgit-sys/README.md delete mode 100644 contrib/libgit-sys/build.rs delete mode 100644 contrib/libgit-sys/public_symbol_export.c delete mode 100644 contrib/libgit-sys/public_symbol_export.h delete mode 100644 contrib/libgit-sys/src/lib.rs delete mode 100755 src/cargo-meson.sh delete mode 100644 src/lib.rs delete mode 100644 src/meson.build delete mode 100644 src/varint.rs diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index f2e93f54611b62..88eb5d3c67e08e 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -468,21 +468,6 @@ jobs: - run: ci/install-dependencies.sh - run: ci/run-static-analysis.sh - run: ci/check-directional-formatting.bash - rust-analysis: - needs: ci-config - if: needs.ci-config.outputs.enabled == 'yes' - env: - jobname: RustAnalysis - CI_JOB_IMAGE: ubuntu:rolling - runs-on: ubuntu-latest - container: ubuntu:rolling - concurrency: - group: rust-analysis-${{ github.ref }} - cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }} - steps: - - uses: actions/checkout@v4 - - run: ci/install-dependencies.sh - - run: ci/run-rust-checks.sh sparse: needs: ci-config if: needs.ci-config.outputs.enabled == 'yes' diff --git a/.gitignore b/.gitignore index 24635cf2d6f4a3..5554ebbfe4a6d1 100644 --- a/.gitignore +++ b/.gitignore @@ -257,5 +257,3 @@ Release/ /git.VC.db *.dSYM /contrib/buildsystems/out -/contrib/libgit-rs/target -/contrib/libgit-sys/target diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index b419a84e2cc660..f7d57d1ee96528 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -161,7 +161,7 @@ test:mingw64: - saas-windows-medium-amd64 before_script: - *windows_before_script - - choco install -y git meson ninja rust-ms + - choco install -y git meson ninja - Import-Module $env:ChocolateyInstall\helpers\chocolateyProfile.psm1 - refreshenv @@ -212,17 +212,6 @@ static-analysis: - ./ci/run-static-analysis.sh - ./ci/check-directional-formatting.bash -rust-analysis: - image: ubuntu:rolling - stage: analyze - needs: [ ] - variables: - jobname: RustAnalysis - before_script: - - ./ci/install-dependencies.sh - script: - - ./ci/run-rust-checks.sh - check-whitespace: image: ubuntu:latest stage: analyze diff --git a/Cargo.toml b/Cargo.toml deleted file mode 100644 index 2f51bf5d5ff5f8..00000000000000 --- a/Cargo.toml +++ /dev/null @@ -1,10 +0,0 @@ -[package] -name = "gitcore" -version = "0.1.0" -edition = "2018" -rust-version = "1.49.0" - -[lib] -crate-type = ["staticlib"] - -[dependencies] diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc index f814450d2f65ac..c874b208ba6be2 100644 --- a/Documentation/BreakingChanges.adoc +++ b/Documentation/BreakingChanges.adoc @@ -170,52 +170,7 @@ JGit, libgit2 and Gitoxide need to support it. provide useful advice about init.defaultBranch, 2020-12-11). The new name matches the default branch name used in new repositories by many of the big Git forges. - -* Git will require Rust as a mandatory part of the build process. While Git - already started to adopt Rust in Git 2.49, all parts written in Rust are - optional for the time being. This includes: -+ - ** The Rust wrapper around libgit.a that is part of "contrib/" and which has - been introduced in Git 2.49. - ** Subsystems that have an alternative implementation in Rust to test - interoperability between our C and Rust codebase. - ** Newly written features that are not mission critical for a fully functional - Git client. -+ -These changes are meant as test balloons to allow distributors of Git to prepare -for Rust becoming a mandatory part of the build process. There will be multiple -milestones for the introduction of Rust: -+ --- -1. Initially, with Git 2.52, support for Rust will be auto-detected by Meson and - disabled in our Makefile so that the project can sort out the initial - infrastructure. -2. In Git 2.53, both build systems will default-enable support for Rust. - Consequently, builds will break by default if Rust is not available on the - build host. The use of Rust can still be explicitly disabled via build - flags. -3. In Git 3.0, the build options will be removed and support for Rust is - mandatory. --- + -You can explicitly ask both Meson and our Makefile-based system to enable Rust -by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`, -respectively. -+ -The Git project will declare the last version before Git 3.0 to be a long-term -support release. This long-term release will receive important bug fixes for at -least four release cycles and security fixes for six release cycles. The Git -project will hand over maintainership of the long-term release to distributors -in case they need to extend the life of that long-term release even further. -Details of how this long-term release will be handed over to the community will -be discussed once the Git project decides to stop officially supporting it. -+ -We will evaluate the impact on downstream distributions before making Rust -mandatory in Git 3.0. If we see that the impact on downstream distributions -would be significant, we may decide to defer this change to a subsequent minor -release. This evaluation will also take into account our own experience with -how painful it is to keep Rust an optional component. - === Removals * Support for grafting commits has long been superseded by git-replace(1). diff --git a/Documentation/technical/build-systems.adoc b/Documentation/technical/build-systems.adoc index 3c5237b9fd4727..b910026b536801 100644 --- a/Documentation/technical/build-systems.adoc +++ b/Documentation/technical/build-systems.adoc @@ -106,8 +106,6 @@ by the build system: - C: the primary compiled language used by Git, must be supported. Relevant toolchains are GCC, Clang and MSVC. - - Rust: candidate as a second compiled lanugage, should be supported. Relevant - toolchains is the LLVM-based rustc. Built-in support for the respective languages is preferred over support that needs to be wired up manually to avoid unnecessary complexity. Native support @@ -151,7 +149,6 @@ The following list of build systems are considered: - Cross-platform builds: supported in theory, not wired up in practice. - Language support: - C: Limited built-in support, many parts need to be wired up manually. - - Rust: No built-in support, needs to be wired up manually. - Test integration: partially supported, many parts need to be wired up manually. @@ -168,7 +165,6 @@ The following list of build systems are considered: - Cross-platform builds: supported. - Language support: - C: Limited built-in support, many parts need to be wired up manually. - - Rust: No built-in support, needs to be wired up manually. - Test integration: partially supported, many parts need to be wired up manually. @@ -194,7 +190,6 @@ The following list of build systems are considered: - Cross-platform builds: supported. - Language support: - C: Supported for GCC, Clang, MSVC and other toolchains. - - Rust: No built-in support, needs to be wired up manually. - Test integration: supported, even though test dependencies are a bit cumbersome to use via "test fixtures". Interactive test runs are not supported. @@ -222,6 +217,5 @@ The following list of build systems are considered: - Cross-platform builds: supported. - Language support: - C: Supported for GCC, Clang, MSVC and other toolchains. - - Rust: Supported for rustc. - Test integration: supported. Interactive tests are supported starting with Meson 1.5.0 via the `--interactive` flag. diff --git a/Makefile b/Makefile index 4ac44331ea1ec0..35205e326058ea 100644 --- a/Makefile +++ b/Makefile @@ -422,9 +422,6 @@ include shared.mak # Define LINK_FUZZ_PROGRAMS if you want `make all` to also build the fuzz test # programs in oss-fuzz/. # -# Define INCLUDE_LIBGIT_RS if you want `make all` and `make test` to build and -# test the Rust crates in contrib/libgit-sys and contrib/libgit-rs. -# # === Optional library: libintl === # # Define NO_GETTEXT if you don't want Git output to be translated. @@ -493,14 +490,6 @@ include shared.mak # Define LIBPCREDIR=/foo/bar if your PCRE header and library files are # in /foo/bar/include and /foo/bar/lib directories. # -# == Optional Rust support == -# -# Define WITH_RUST if you want to include features and subsystems written in -# Rust into Git. For now, Rust is still an optional feature of the build -# process. With Git 3.0 though, Rust will always be enabled. -# -# Building Rust code requires Cargo. -# # == SHA-1 and SHA-256 defines == # # === SHA-1 backend === @@ -695,13 +684,11 @@ FUZZ_OBJS = FUZZ_PROGRAMS = GIT_OBJS = LIB_OBJS = -LIBGIT_PUB_OBJS = SCALAR_OBJS = OBJECTS = OTHER_PROGRAMS = PROGRAM_OBJS = PROGRAMS = -RUST_SOURCES = EXCLUDED_PROGRAMS = SCRIPT_PERL = SCRIPT_PYTHON = @@ -938,18 +925,6 @@ TEST_SHELL_PATH = $(SHELL_PATH) LIB_FILE = libgit.a -ifdef DEBUG -RUST_TARGET_DIR = target/debug -else -RUST_TARGET_DIR = target/release -endif - -ifeq ($(uname_S),Windows) -RUST_LIB = $(RUST_TARGET_DIR)/gitcore.lib -else -RUST_LIB = $(RUST_TARGET_DIR)/libgitcore.a -endif - GITLIBS = common-main.o $(LIB_FILE) EXTLIBS = @@ -973,15 +948,6 @@ BASIC_LDFLAGS = ARFLAGS = rcs PTHREAD_CFLAGS = -# Rust flags -CARGO_ARGS = -ifndef V -CARGO_ARGS += --quiet -endif -ifndef DEBUG -CARGO_ARGS += --release -endif - # For the 'sparse' target SPARSE_FLAGS ?= -std=gnu99 -D__STDC_NO_VLA__ SP_EXTRA_FLAGS = @@ -1344,9 +1310,7 @@ LIB_OBJS += urlmatch.o LIB_OBJS += usage.o LIB_OBJS += userdiff.o LIB_OBJS += utf8.o -ifndef WITH_RUST LIB_OBJS += varint.o -endif LIB_OBJS += version.o LIB_OBJS += versioncmp.o LIB_OBJS += walker.o @@ -1547,9 +1511,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o -RUST_SOURCES += src/lib.rs -RUST_SOURCES += src/varint.rs - GIT-VERSION-FILE: FORCE @OLD=$$(cat $@ 2>/dev/null || :) && \ $(call version_gen,"$(shell pwd)",GIT-VERSION-FILE.in,$@) && \ @@ -1579,14 +1540,6 @@ endif ALL_CFLAGS = $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_APPEND) ALL_LDFLAGS = $(LDFLAGS) $(LDFLAGS_APPEND) -ifdef WITH_RUST -BASIC_CFLAGS += -DWITH_RUST -GITLIBS += $(RUST_LIB) -ifeq ($(uname_S),Windows) -EXTLIBS += -luserenv -endif -endif - ifdef SANITIZE SANITIZERS := $(foreach flag,$(subst $(comma),$(space),$(SANITIZE)),$(flag)) BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE) @@ -2384,12 +2337,6 @@ ifdef CHECK_ASSERTION_SIDE_EFFECTS BASIC_CFLAGS += -DCHECK_ASSERTION_SIDE_EFFECTS endif -ifdef INCLUDE_LIBGIT_RS - # Enable symbol hiding in contrib/libgit-sys/libgitpub.a without making - # us rebuild the whole tree every time we run a Rust build. - BASIC_CFLAGS += -fvisibility=hidden -endif - ifeq ($(TCLTK_PATH),) NO_TCLTK = NoThanks endif @@ -2862,10 +2809,6 @@ OBJECTS += $(UNIT_TEST_OBJS) OBJECTS += $(CLAR_TEST_OBJS) OBJECTS += $(patsubst %,$(UNIT_TEST_DIR)/%.o,$(UNIT_TEST_PROGRAMS)) -ifdef INCLUDE_LIBGIT_RS - OBJECTS += contrib/libgit-sys/public_symbol_export.o -endif - ifndef NO_CURL OBJECTS += http.o http-walker.o remote-curl.o endif @@ -3009,12 +2952,6 @@ scalar$X: scalar.o GIT-LDFLAGS $(GITLIBS) $(LIB_FILE): $(LIB_OBJS) $(QUIET_AR)$(RM) $@ && $(AR) $(ARFLAGS) $@ $^ -$(RUST_LIB): Cargo.toml $(RUST_SOURCES) - $(QUIET_CARGO)cargo build $(CARGO_ARGS) - -.PHONY: rust -rust: $(RUST_LIB) - export DEFAULT_EDITOR DEFAULT_PAGER Documentation/GIT-EXCLUDED-PROGRAMS: FORCE @@ -3870,10 +3807,6 @@ clean: profile-clean coverage-clean cocciclean $(RM) $(htmldocs).tar.gz $(manpages).tar.gz $(MAKE) -C Documentation/ clean $(RM) Documentation/GIT-EXCLUDED-PROGRAMS - $(RM) -r contrib/libgit-sys/target contrib/libgit-rs/target - $(RM) contrib/libgit-sys/partial_symbol_export.o - $(RM) contrib/libgit-sys/hidden_symbol_export.o - $(RM) contrib/libgit-sys/libgitpub.a ifndef NO_PERL $(RM) -r perl/build/ endif @@ -4035,28 +3968,3 @@ $(CLAR_TEST_PROG): $(UNIT_TEST_DIR)/clar.suite $(CLAR_TEST_OBJS) $(GITLIBS) GIT- build-unit-tests: $(UNIT_TEST_PROGS) $(CLAR_TEST_PROG) unit-tests: $(UNIT_TEST_PROGS) $(CLAR_TEST_PROG) t/helper/test-tool$X $(MAKE) -C t/ unit-tests - -.PHONY: libgit-sys libgit-rs -libgit-sys: - $(QUIET)cargo build --manifest-path contrib/libgit-sys/Cargo.toml -libgit-rs: libgit-sys - $(QUIET)cargo build --manifest-path contrib/libgit-rs/Cargo.toml -ifdef INCLUDE_LIBGIT_RS -all:: libgit-rs -endif - -LIBGIT_PUB_OBJS += contrib/libgit-sys/public_symbol_export.o -LIBGIT_PUB_OBJS += libgit.a - -LIBGIT_PARTIAL_EXPORT = contrib/libgit-sys/partial_symbol_export.o - -LIBGIT_HIDDEN_EXPORT = contrib/libgit-sys/hidden_symbol_export.o - -$(LIBGIT_PARTIAL_EXPORT): $(LIBGIT_PUB_OBJS) - $(LD) -r $^ -o $@ - -$(LIBGIT_HIDDEN_EXPORT): $(LIBGIT_PARTIAL_EXPORT) - $(OBJCOPY) --localize-hidden $^ $@ - -contrib/libgit-sys/libgitpub.a: $(LIBGIT_HIDDEN_EXPORT) - $(AR) $(ARFLAGS) $@ $^ diff --git a/README.md b/README.md index d87bca1b8c3ebf..249e92974e7f6f 100644 --- a/README.md +++ b/README.md @@ -3,6 +3,8 @@ Git - fast, scalable, distributed revision control system ========================================================= +Git with WD-40 applied. + Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh index 6ee8216a05e127..7eb1d0dd07fe29 100755 --- a/ci/install-dependencies.sh +++ b/ci/install-dependencies.sh @@ -137,17 +137,6 @@ StaticAnalysis) sudo apt-get -q -y install coccinelle libcurl4-openssl-dev libssl-dev \ libexpat-dev gettext make ;; -RustAnalysis) - sudo apt-get -q -y install rustup - rustup default stable - rustup component add clippy rustfmt - - wget -q "$CARGO_MSRV_WHENCE" -O "cargo-msvc.tgz" - sudo mkdir -p "$CUSTOM_PATH" - sudo tar -xf "cargo-msvc.tgz" --strip-components=1 \ - --directory "$CUSTOM_PATH" --wildcards "*/cargo-msrv" - sudo chmod a+x "$CUSTOM_PATH/cargo-msrv" - ;; sparse) sudo apt-get -q -y install libssl-dev libcurl4-openssl-dev \ libexpat-dev gettext zlib1g-dev sparse diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh index 8bda62b921920f..d91aa9227c6759 100755 --- a/ci/run-build-and-tests.sh +++ b/ci/run-build-and-tests.sh @@ -1,3 +1,4 @@ + #!/bin/sh # # Build and test Git @@ -8,7 +9,6 @@ case "$jobname" in fedora-breaking-changes-musl|linux-breaking-changes) export WITH_BREAKING_CHANGES=YesPlease - export WITH_RUST=YesPlease MESONFLAGS="$MESONFLAGS -Dbreaking_changes=true" MESONFLAGS="$MESONFLAGS -Drust=enabled" ;; diff --git a/ci/run-rust-checks.sh b/ci/run-rust-checks.sh deleted file mode 100755 index b5ad9e8dc6f71f..00000000000000 --- a/ci/run-rust-checks.sh +++ /dev/null @@ -1,22 +0,0 @@ -#!/bin/sh - -. ${0%/*}/lib.sh - -set +x - -if ! group "Check Rust formatting" cargo fmt --all --check -then - RET=1 -fi - -if ! group "Check for common Rust mistakes" cargo clippy --all-targets --all-features -- -Dwarnings -then - RET=1 -fi - -if ! group "Check for minimum required Rust version" cargo msrv verify -then - RET=1 -fi - -exit $RET diff --git a/contrib/libgit-rs/Cargo.lock b/contrib/libgit-rs/Cargo.lock deleted file mode 100644 index a30c7c8d33ee30..00000000000000 --- a/contrib/libgit-rs/Cargo.lock +++ /dev/null @@ -1,77 +0,0 @@ -# This file is automatically @generated by Cargo. -# It is not intended for manual editing. -version = 3 - -[[package]] -name = "autocfg" -version = "1.4.0" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "ace50bade8e6234aa140d9a2f552bbee1db4d353f69b8217bc503490fc1a9f26" - -[[package]] -name = "cc" -version = "1.1.15" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "57b6a275aa2903740dc87da01c62040406b8812552e97129a63ea8850a17c6e6" -dependencies = [ - "shlex", -] - -[[package]] -name = "libc" -version = "0.2.158" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d8adc4bb1803a324070e64a98ae98f38934d91957a99cfb3a43dcbc01bc56439" - -[[package]] -name = "libgit" -version = "0.1.0" -dependencies = [ - "autocfg", - "libgit-sys", -] - -[[package]] -name = "libgit-sys" -version = "0.1.0" -dependencies = [ - "autocfg", - "libz-sys", - "make-cmd", -] - -[[package]] -name = "libz-sys" -version = "1.1.20" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d2d16453e800a8cf6dd2fc3eb4bc99b786a9b90c663b8559a5b1a041bf89e472" -dependencies = [ - "cc", - "libc", - "pkg-config", - "vcpkg", -] - -[[package]] -name = "make-cmd" -version = "0.1.0" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "a8ca8afbe8af1785e09636acb5a41e08a765f5f0340568716c18a8700ba3c0d3" - -[[package]] -name = "pkg-config" -version = "0.3.30" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d231b230927b5e4ad203db57bbcbee2802f6bce620b1e4a9024a07d94e2907ec" - -[[package]] -name = "shlex" -version = "1.3.0" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "0fda2ff0d084019ba4d7c6f371c95d8fd75ce3524c3cb8fb653a3023f6323e64" - -[[package]] -name = "vcpkg" -version = "0.2.15" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "accd4ea62f7bb7a82fe23066fb0957d48ef677f6eeb8215f372f52e48bb32426" diff --git a/contrib/libgit-rs/Cargo.toml b/contrib/libgit-rs/Cargo.toml deleted file mode 100644 index c3289e69db5939..00000000000000 --- a/contrib/libgit-rs/Cargo.toml +++ /dev/null @@ -1,17 +0,0 @@ -[package] -name = "libgit" -version = "0.1.0" -edition = "2021" -build = "build.rs" -rust-version = "1.63" # TODO: Once we hit 1.84 or newer, we may want to remove Cargo.lock from - # version control. See https://lore.kernel.org/git/Z47jgK-oMjFRSslr@tapette.crustytoothpaste.net/ - - -[lib] -path = "src/lib.rs" - -[dependencies] -libgit-sys = { version = "0.1.0", path = "../libgit-sys" } - -[build-dependencies] -autocfg = "1.4.0" diff --git a/contrib/libgit-rs/README.md b/contrib/libgit-rs/README.md deleted file mode 100644 index ff945e1ce207e5..00000000000000 --- a/contrib/libgit-rs/README.md +++ /dev/null @@ -1,13 +0,0 @@ -# libgit-rs - -Proof-of-concept Git bindings for Rust. - -```toml -[dependencies] -libgit = "0.1.0" -``` - -## Rust version requirements - -libgit-rs should support Rust versions at least as old as the version included -in Debian stable (currently 1.63). diff --git a/contrib/libgit-rs/build.rs b/contrib/libgit-rs/build.rs deleted file mode 100644 index f8bd01a690b1eb..00000000000000 --- a/contrib/libgit-rs/build.rs +++ /dev/null @@ -1,4 +0,0 @@ -pub fn main() { - let ac = autocfg::new(); - ac.emit_has_path("std::ffi::c_char"); -} diff --git a/contrib/libgit-rs/src/config.rs b/contrib/libgit-rs/src/config.rs deleted file mode 100644 index 6bf04845c8f01b..00000000000000 --- a/contrib/libgit-rs/src/config.rs +++ /dev/null @@ -1,106 +0,0 @@ -use std::ffi::{c_void, CStr, CString}; -use std::path::Path; - -#[cfg(has_std__ffi__c_char)] -use std::ffi::{c_char, c_int}; - -#[cfg(not(has_std__ffi__c_char))] -#[allow(non_camel_case_types)] -type c_char = i8; - -#[cfg(not(has_std__ffi__c_char))] -#[allow(non_camel_case_types)] -type c_int = i32; - -use libgit_sys::*; - -/// A ConfigSet is an in-memory cache for config-like files such as `.gitmodules` or `.gitconfig`. -/// It does not support all config directives; notably, it will not process `include` or -/// `includeIf` directives (but it will store them so that callers can choose whether and how to -/// handle them). -pub struct ConfigSet(*mut libgit_config_set); -impl ConfigSet { - /// Allocate a new ConfigSet - pub fn new() -> Self { - unsafe { ConfigSet(libgit_configset_alloc()) } - } - - /// Load the given files into the ConfigSet; conflicting directives in later files will - /// override those given in earlier files. - pub fn add_files(&mut self, files: &[&Path]) { - for file in files { - let pstr = file.to_str().expect("Invalid UTF-8"); - let rs = CString::new(pstr).expect("Couldn't convert to CString"); - unsafe { - libgit_configset_add_file(self.0, rs.as_ptr()); - } - } - } - - /// Load the value for the given key and attempt to parse it as an i32. Dies with a fatal error - /// if the value cannot be parsed. Returns None if the key is not present. - pub fn get_int(&mut self, key: &str) -> Option { - let key = CString::new(key).expect("Couldn't convert to CString"); - let mut val: c_int = 0; - unsafe { - if libgit_configset_get_int(self.0, key.as_ptr(), &mut val as *mut c_int) != 0 { - return None; - } - } - - Some(val.into()) - } - - /// Clones the value for the given key. Dies with a fatal error if the value cannot be - /// converted to a String. Returns None if the key is not present. - pub fn get_string(&mut self, key: &str) -> Option { - let key = CString::new(key).expect("Couldn't convert key to CString"); - let mut val: *mut c_char = std::ptr::null_mut(); - unsafe { - if libgit_configset_get_string(self.0, key.as_ptr(), &mut val as *mut *mut c_char) != 0 - { - return None; - } - let borrowed_str = CStr::from_ptr(val); - let owned_str = - String::from(borrowed_str.to_str().expect("Couldn't convert val to str")); - free(val as *mut c_void); // Free the xstrdup()ed pointer from the C side - Some(owned_str) - } - } -} - -impl Default for ConfigSet { - fn default() -> Self { - Self::new() - } -} - -impl Drop for ConfigSet { - fn drop(&mut self) { - unsafe { - libgit_configset_free(self.0); - } - } -} - -#[cfg(test)] -mod tests { - use super::*; - - #[test] - fn load_configs_via_configset() { - let mut cs = ConfigSet::new(); - cs.add_files(&[ - Path::new("testdata/config1"), - Path::new("testdata/config2"), - Path::new("testdata/config3"), - ]); - // ConfigSet retrieves correct value - assert_eq!(cs.get_int("trace2.eventTarget"), Some(1)); - // ConfigSet respects last config value set - assert_eq!(cs.get_int("trace2.eventNesting"), Some(3)); - // ConfigSet returns None for missing key - assert_eq!(cs.get_string("foo.bar"), None); - } -} diff --git a/contrib/libgit-rs/src/lib.rs b/contrib/libgit-rs/src/lib.rs deleted file mode 100644 index ef68c36943d46d..00000000000000 --- a/contrib/libgit-rs/src/lib.rs +++ /dev/null @@ -1 +0,0 @@ -pub mod config; diff --git a/contrib/libgit-rs/testdata/config1 b/contrib/libgit-rs/testdata/config1 deleted file mode 100644 index 4e9a9d25d1ffe8..00000000000000 --- a/contrib/libgit-rs/testdata/config1 +++ /dev/null @@ -1,2 +0,0 @@ -[trace2] - eventNesting = 1 diff --git a/contrib/libgit-rs/testdata/config2 b/contrib/libgit-rs/testdata/config2 deleted file mode 100644 index b8d1eca4235f20..00000000000000 --- a/contrib/libgit-rs/testdata/config2 +++ /dev/null @@ -1,2 +0,0 @@ -[trace2] - eventTarget = 1 diff --git a/contrib/libgit-rs/testdata/config3 b/contrib/libgit-rs/testdata/config3 deleted file mode 100644 index ca7b9a7c38039c..00000000000000 --- a/contrib/libgit-rs/testdata/config3 +++ /dev/null @@ -1,2 +0,0 @@ -[trace2] - eventNesting = 3 diff --git a/contrib/libgit-sys/Cargo.lock b/contrib/libgit-sys/Cargo.lock deleted file mode 100644 index 427a4c66b7e2cd..00000000000000 --- a/contrib/libgit-sys/Cargo.lock +++ /dev/null @@ -1,69 +0,0 @@ -# This file is automatically @generated by Cargo. -# It is not intended for manual editing. -version = 3 - -[[package]] -name = "autocfg" -version = "1.4.0" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "ace50bade8e6234aa140d9a2f552bbee1db4d353f69b8217bc503490fc1a9f26" - -[[package]] -name = "cc" -version = "1.1.15" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "57b6a275aa2903740dc87da01c62040406b8812552e97129a63ea8850a17c6e6" -dependencies = [ - "shlex", -] - -[[package]] -name = "libc" -version = "0.2.158" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d8adc4bb1803a324070e64a98ae98f38934d91957a99cfb3a43dcbc01bc56439" - -[[package]] -name = "libgit-sys" -version = "0.1.0" -dependencies = [ - "autocfg", - "libz-sys", - "make-cmd", -] - -[[package]] -name = "libz-sys" -version = "1.1.20" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d2d16453e800a8cf6dd2fc3eb4bc99b786a9b90c663b8559a5b1a041bf89e472" -dependencies = [ - "cc", - "libc", - "pkg-config", - "vcpkg", -] - -[[package]] -name = "make-cmd" -version = "0.1.0" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "a8ca8afbe8af1785e09636acb5a41e08a765f5f0340568716c18a8700ba3c0d3" - -[[package]] -name = "pkg-config" -version = "0.3.30" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d231b230927b5e4ad203db57bbcbee2802f6bce620b1e4a9024a07d94e2907ec" - -[[package]] -name = "shlex" -version = "1.3.0" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "0fda2ff0d084019ba4d7c6f371c95d8fd75ce3524c3cb8fb653a3023f6323e64" - -[[package]] -name = "vcpkg" -version = "0.2.15" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "accd4ea62f7bb7a82fe23066fb0957d48ef677f6eeb8215f372f52e48bb32426" diff --git a/contrib/libgit-sys/Cargo.toml b/contrib/libgit-sys/Cargo.toml deleted file mode 100644 index e0623022c35f01..00000000000000 --- a/contrib/libgit-sys/Cargo.toml +++ /dev/null @@ -1,19 +0,0 @@ -[package] -name = "libgit-sys" -version = "0.1.0" -edition = "2021" -build = "build.rs" -links = "gitpub" -rust-version = "1.63" # TODO: Once we hit 1.84 or newer, we may want to remove Cargo.lock from - # version control. See https://lore.kernel.org/git/Z47jgK-oMjFRSslr@tapette.crustytoothpaste.net/ -description = "Native bindings to a portion of libgit" - -[lib] -path = "src/lib.rs" - -[dependencies] -libz-sys = "1.1.19" - -[build-dependencies] -autocfg = "1.4.0" -make-cmd = "0.1.0" diff --git a/contrib/libgit-sys/README.md b/contrib/libgit-sys/README.md deleted file mode 100644 index c061cfcaf58f4d..00000000000000 --- a/contrib/libgit-sys/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# libgit-sys - -A small proof-of-concept crate showing how to provide a Rust FFI to Git -internals. diff --git a/contrib/libgit-sys/build.rs b/contrib/libgit-sys/build.rs deleted file mode 100644 index 3ffd80ad91075c..00000000000000 --- a/contrib/libgit-sys/build.rs +++ /dev/null @@ -1,35 +0,0 @@ -use std::env; -use std::path::PathBuf; - -pub fn main() -> std::io::Result<()> { - let ac = autocfg::new(); - ac.emit_has_path("std::ffi::c_char"); - - let crate_root = PathBuf::from(env::var_os("CARGO_MANIFEST_DIR").unwrap()); - let git_root = crate_root.join("../.."); - let dst = PathBuf::from(env::var_os("OUT_DIR").unwrap()); - - let make_output = make_cmd::gnu_make() - .env("DEVELOPER", "1") - .env_remove("PROFILE") - .current_dir(git_root.clone()) - .args([ - "INCLUDE_LIBGIT_RS=YesPlease", - "contrib/libgit-sys/libgitpub.a", - ]) - .output() - .expect("Make failed to run"); - if !make_output.status.success() { - panic!( - "Make failed:\n stdout = {}\n stderr = {}\n", - String::from_utf8(make_output.stdout).unwrap(), - String::from_utf8(make_output.stderr).unwrap() - ); - } - std::fs::copy(crate_root.join("libgitpub.a"), dst.join("libgitpub.a"))?; - println!("cargo:rustc-link-search=native={}", dst.display()); - println!("cargo:rustc-link-lib=gitpub"); - println!("cargo:rerun-if-changed={}", git_root.display()); - - Ok(()) -} diff --git a/contrib/libgit-sys/public_symbol_export.c b/contrib/libgit-sys/public_symbol_export.c deleted file mode 100644 index dfbb2571152d6e..00000000000000 --- a/contrib/libgit-sys/public_symbol_export.c +++ /dev/null @@ -1,59 +0,0 @@ -/* - * Shim to publicly export Git symbols. These must be renamed so that the - * original symbols can be hidden. Renaming these with a "libgit_" prefix also - * avoids conflicts with other libraries such as libgit2. - */ - -#include "git-compat-util.h" -#include "config.h" -#include "contrib/libgit-sys/public_symbol_export.h" -#include "version.h" - -#pragma GCC visibility push(default) - -struct libgit_config_set { - struct config_set cs; -}; - -struct libgit_config_set *libgit_configset_alloc(void) -{ - struct libgit_config_set *cs = - xmalloc(sizeof(struct libgit_config_set)); - git_configset_init(&cs->cs); - return cs; -} - -void libgit_configset_free(struct libgit_config_set *cs) -{ - git_configset_clear(&cs->cs); - free(cs); -} - -int libgit_configset_add_file(struct libgit_config_set *cs, const char *filename) -{ - return git_configset_add_file(&cs->cs, filename); -} - -int libgit_configset_get_int(struct libgit_config_set *cs, const char *key, - int *dest) -{ - return git_configset_get_int(&cs->cs, key, dest); -} - -int libgit_configset_get_string(struct libgit_config_set *cs, const char *key, - char **dest) -{ - return git_configset_get_string(&cs->cs, key, dest); -} - -const char *libgit_user_agent(void) -{ - return git_user_agent(); -} - -const char *libgit_user_agent_sanitized(void) -{ - return git_user_agent_sanitized(); -} - -#pragma GCC visibility pop diff --git a/contrib/libgit-sys/public_symbol_export.h b/contrib/libgit-sys/public_symbol_export.h deleted file mode 100644 index 701db92d53461d..00000000000000 --- a/contrib/libgit-sys/public_symbol_export.h +++ /dev/null @@ -1,18 +0,0 @@ -#ifndef PUBLIC_SYMBOL_EXPORT_H -#define PUBLIC_SYMBOL_EXPORT_H - -struct libgit_config_set *libgit_configset_alloc(void); - -void libgit_configset_free(struct libgit_config_set *cs); - -int libgit_configset_add_file(struct libgit_config_set *cs, const char *filename); - -int libgit_configset_get_int(struct libgit_config_set *cs, const char *key, int *dest); - -int libgit_configset_get_string(struct libgit_config_set *cs, const char *key, char **dest); - -const char *libgit_user_agent(void); - -const char *libgit_user_agent_sanitized(void); - -#endif /* PUBLIC_SYMBOL_EXPORT_H */ diff --git a/contrib/libgit-sys/src/lib.rs b/contrib/libgit-sys/src/lib.rs deleted file mode 100644 index 4bfc65045026cf..00000000000000 --- a/contrib/libgit-sys/src/lib.rs +++ /dev/null @@ -1,79 +0,0 @@ -use std::ffi::c_void; - -#[cfg(has_std__ffi__c_char)] -use std::ffi::{c_char, c_int}; - -#[cfg(not(has_std__ffi__c_char))] -#[allow(non_camel_case_types)] -pub type c_char = i8; - -#[cfg(not(has_std__ffi__c_char))] -#[allow(non_camel_case_types)] -pub type c_int = i32; - -extern crate libz_sys; - -#[allow(non_camel_case_types)] -#[repr(C)] -pub struct libgit_config_set { - _data: [u8; 0], - _marker: core::marker::PhantomData<(*mut u8, core::marker::PhantomPinned)>, -} - -extern "C" { - pub fn free(ptr: *mut c_void); - - pub fn libgit_user_agent() -> *const c_char; - pub fn libgit_user_agent_sanitized() -> *const c_char; - - pub fn libgit_configset_alloc() -> *mut libgit_config_set; - pub fn libgit_configset_free(cs: *mut libgit_config_set); - - pub fn libgit_configset_add_file(cs: *mut libgit_config_set, filename: *const c_char) -> c_int; - - pub fn libgit_configset_get_int( - cs: *mut libgit_config_set, - key: *const c_char, - int: *mut c_int, - ) -> c_int; - - pub fn libgit_configset_get_string( - cs: *mut libgit_config_set, - key: *const c_char, - dest: *mut *mut c_char, - ) -> c_int; - -} - -#[cfg(test)] -mod tests { - use std::ffi::CStr; - - use super::*; - - #[test] - fn user_agent_starts_with_git() { - let c_str = unsafe { CStr::from_ptr(libgit_user_agent()) }; - let agent = c_str - .to_str() - .expect("User agent contains invalid UTF-8 data"); - assert!( - agent.starts_with("git/"), - r#"Expected user agent to start with "git/", got: {}"#, - agent - ); - } - - #[test] - fn sanitized_user_agent_starts_with_git() { - let c_str = unsafe { CStr::from_ptr(libgit_user_agent_sanitized()) }; - let agent = c_str - .to_str() - .expect("Sanitized user agent contains invalid UTF-8 data"); - assert!( - agent.starts_with("git/"), - r#"Expected user agent to start with "git/", got: {}"#, - agent - ); - } -} diff --git a/help.c b/help.c index fefd811f7a041f..f40b4a55e5c0a8 100644 --- a/help.c +++ b/help.c @@ -1,3 +1,4 @@ + #define USE_THE_REPOSITORY_VARIABLE #define DISABLE_SIGN_COMPARE_WARNINGS @@ -790,12 +791,6 @@ void get_version_info(struct strbuf *buf, int show_build_options) strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH); /* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */ -#if defined WITH_RUST - strbuf_addstr(buf, "rust: enabled\n"); -#else - strbuf_addstr(buf, "rust: disabled\n"); -#endif - if (fsmonitor_ipc__is_supported()) strbuf_addstr(buf, "feature: fsmonitor--daemon\n"); #if !defined NO_GETTEXT diff --git a/meson.build b/meson.build index 3a1d12caa4b94f..97d65c8ae8429c 100644 --- a/meson.build +++ b/meson.build @@ -1722,20 +1722,9 @@ version_def_h = custom_target( ) libgit_sources += version_def_h -cargo = find_program('cargo', dirs: program_path, native: true, required: get_option('rust')) -rust_option = get_option('rust').disable_auto_if(not cargo.found()) -if rust_option.allowed() - subdir('src') - libgit_c_args += '-DWITH_RUST' - - if host_machine.system() == 'windows' - libgit_dependencies += compiler.find_library('userenv') - endif -else - libgit_sources += [ +libgit_sources += [ 'varint.c', - ] -endif +] libgit = declare_dependency( link_with: static_library('git', diff --git a/src/cargo-meson.sh b/src/cargo-meson.sh deleted file mode 100755 index 38728a371137f9..00000000000000 --- a/src/cargo-meson.sh +++ /dev/null @@ -1,39 +0,0 @@ -#!/bin/sh - -if test "$#" -lt 2 -then - exit 1 -fi - -SOURCE_DIR="$1" -BUILD_DIR="$2" -BUILD_TYPE=debug - -shift 2 - -for arg -do - case "$arg" in - --release) - BUILD_TYPE=release;; - esac -done - -cargo build --lib --quiet --manifest-path="$SOURCE_DIR/Cargo.toml" --target-dir="$BUILD_DIR" "$@" -RET=$? -if test $RET -ne 0 -then - exit $RET -fi - -case "$(cargo -vV | sed -n 's/^host: \(.*\)$/\1/p')" in - *-windows-*) - LIBNAME=gitcore.lib;; - *) - LIBNAME=libgitcore.a;; -esac - -if ! cmp "$BUILD_DIR/$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a" >/dev/null 2>&1 -then - cp "$BUILD_DIR/$BUILD_TYPE/$LIBNAME" "$BUILD_DIR/libgitcore.a" -fi diff --git a/src/lib.rs b/src/lib.rs deleted file mode 100644 index 9da70d8b57d5f6..00000000000000 --- a/src/lib.rs +++ /dev/null @@ -1 +0,0 @@ -pub mod varint; diff --git a/src/meson.build b/src/meson.build deleted file mode 100644 index 25b9ad5a1479c0..00000000000000 --- a/src/meson.build +++ /dev/null @@ -1,41 +0,0 @@ -libgit_rs_sources = [ - 'lib.rs', - 'varint.rs', -] - -# Unfortunately we must use a wrapper command to move the output file into the -# current build directory. This can fixed once `cargo build --artifact-dir` -# stabilizes. See https://github.com/rust-lang/cargo/issues/6790 for that -# effort. -cargo_command = [ - shell, - meson.current_source_dir() / 'cargo-meson.sh', - meson.project_source_root(), - meson.current_build_dir(), -] -if get_option('buildtype') == 'release' - cargo_command += '--release' -endif - -libgit_rs = custom_target('git_rs', - input: libgit_rs_sources + [ - meson.project_source_root() / 'Cargo.toml', - ], - output: 'libgitcore.a', - command: cargo_command, -) -libgit_dependencies += declare_dependency(link_with: libgit_rs) - -if get_option('tests') - test('rust', cargo, - args: [ - 'test', - '--manifest-path', - meson.project_source_root() / 'Cargo.toml', - '--target-dir', - meson.current_build_dir() / 'target', - ], - timeout: 0, - protocol: 'rust', - ) -endif diff --git a/src/varint.rs b/src/varint.rs deleted file mode 100644 index 06492dfc5eaeef..00000000000000 --- a/src/varint.rs +++ /dev/null @@ -1,107 +0,0 @@ -/// Decode the variable-length integer stored in `bufp` and return the decoded value. -/// -/// Returns 0 in case the decoded integer would overflow u64::MAX. -/// -/// # Safety -/// -/// The buffer must be NUL-terminated to ensure safety. -#[no_mangle] -pub unsafe extern "C" fn decode_varint(bufp: *mut *const u8) -> u64 { - let mut buf = *bufp; - let mut c = *buf; - let mut val = u64::from(c & 127); - - buf = buf.add(1); - - while (c & 128) != 0 { - val = val.wrapping_add(1); - if val == 0 || val.leading_zeros() < 7 { - return 0; // overflow - } - - c = *buf; - buf = buf.add(1); - - val = (val << 7) + u64::from(c & 127); - } - - *bufp = buf; - val -} - -/// Encode `value` into `buf` as a variable-length integer unless `buf` is null. -/// -/// Returns the number of bytes written, or, if `buf` is null, the number of bytes that would be -/// written to encode the integer. -/// -/// # Safety -/// -/// `buf` must either be null or point to at least 16 bytes of memory. -#[no_mangle] -pub unsafe extern "C" fn encode_varint(value: u64, buf: *mut u8) -> u8 { - let mut varint: [u8; 16] = [0; 16]; - let mut pos = varint.len() - 1; - - varint[pos] = (value & 127) as u8; - - let mut value = value >> 7; - while value != 0 { - pos -= 1; - value -= 1; - varint[pos] = 128 | (value & 127) as u8; - value >>= 7; - } - - if !buf.is_null() { - std::ptr::copy_nonoverlapping(varint.as_ptr().add(pos), buf, varint.len() - pos); - } - - (varint.len() - pos) as u8 -} - -#[cfg(test)] -mod tests { - use super::*; - - #[test] - fn test_decode_varint() { - unsafe { - assert_eq!(decode_varint(&mut [0x00].as_slice().as_ptr()), 0); - assert_eq!(decode_varint(&mut [0x01].as_slice().as_ptr()), 1); - assert_eq!(decode_varint(&mut [0x7f].as_slice().as_ptr()), 127); - assert_eq!(decode_varint(&mut [0x80, 0x00].as_slice().as_ptr()), 128); - assert_eq!(decode_varint(&mut [0x80, 0x01].as_slice().as_ptr()), 129); - assert_eq!(decode_varint(&mut [0x80, 0x7f].as_slice().as_ptr()), 255); - - // Overflows are expected to return 0. - assert_eq!(decode_varint(&mut [0x88; 16].as_slice().as_ptr()), 0); - } - } - - #[test] - fn test_encode_varint() { - unsafe { - let mut varint: [u8; 16] = [0; 16]; - - assert_eq!(encode_varint(0, std::ptr::null_mut()), 1); - - assert_eq!(encode_varint(0, varint.as_mut_slice().as_mut_ptr()), 1); - assert_eq!(varint, [0; 16]); - - assert_eq!(encode_varint(10, varint.as_mut_slice().as_mut_ptr()), 1); - assert_eq!(varint, [10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]); - - assert_eq!(encode_varint(127, varint.as_mut_slice().as_mut_ptr()), 1); - assert_eq!(varint, [127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]); - - assert_eq!(encode_varint(128, varint.as_mut_slice().as_mut_ptr()), 2); - assert_eq!(varint, [128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]); - - assert_eq!(encode_varint(129, varint.as_mut_slice().as_mut_ptr()), 2); - assert_eq!(varint, [128, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]); - - assert_eq!(encode_varint(255, varint.as_mut_slice().as_mut_ptr()), 2); - assert_eq!(varint, [128, 127, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]); - } - } -} diff --git a/t/Makefile b/t/Makefile index ab8a5b54aa6ce0..e9cc9f28e3a87c 100644 --- a/t/Makefile +++ b/t/Makefile @@ -192,6 +192,3 @@ libgit-sys-test: $(QUIET)cargo test --manifest-path ../contrib/libgit-sys/Cargo.toml libgit-rs-test: libgit-sys-test $(QUIET)cargo test --manifest-path ../contrib/libgit-rs/Cargo.toml -ifdef INCLUDE_LIBGIT_RS -all:: libgit-rs-test -endif From 2221049e906d08014a628fbc27123346ab87692b Mon Sep 17 00:00:00 2001 From: Artur Manuel Date: Sat, 14 Feb 2026 02:51:36 +0000 Subject: [PATCH 2/2] remove mentions of git from the project --- .github/CONTRIBUTING.md | 23 -- .github/PULL_REQUEST_TEMPLATE.md | 10 - CODE_OF_CONDUCT.md | 145 --------- Documentation/BreakingChanges.adoc | 290 ------------------ README.md | 64 +--- SECURITY.md | 51 ---- git-gui/README.md | 133 --------- gitk-git/README.md | 26 -- po/README.md | 460 ----------------------------- 9 files changed, 1 insertion(+), 1201 deletions(-) delete mode 100644 .github/CONTRIBUTING.md delete mode 100644 .github/PULL_REQUEST_TEMPLATE.md delete mode 100644 CODE_OF_CONDUCT.md delete mode 100644 Documentation/BreakingChanges.adoc delete mode 100644 SECURITY.md delete mode 100644 po/README.md diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md deleted file mode 100644 index 93042128d60d21..00000000000000 --- a/.github/CONTRIBUTING.md +++ /dev/null @@ -1,23 +0,0 @@ -## Contributing to Git - -Thanks for taking the time to contribute to Git! Please be advised that the -Git community does not use github.com for their contributions. Instead, we use -a mailing list (git@vger.kernel.org) for code submissions, code -reviews, and bug reports. - -Nevertheless, you can use [GitGitGadget](https://gitgitgadget.github.io/) to -conveniently send your Pull Requests commits to our mailing list. - -Please read ["A note from the maintainer"](https://git.kernel.org/pub/scm/git/git.git/plain/MaintNotes?h=todo) -to learn how the Git project is managed, and how you can work with it. -In addition, we highly recommend you to read -[our submission guidelines](https://git-scm.com/docs/SubmittingPatches). - -If you prefer video, then [this talk](https://www.youtube.com/watch?v=Q7i_qQW__q4&feature=youtu.be&t=6m4s) -might be useful to you as the presenter walks you through the contribution -process by example. - -Or, you can follow the ["My First Contribution"](https://git-scm.com/docs/MyFirstContribution) -tutorial for another example of the contribution process. - -Your friendly Git community! diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md deleted file mode 100644 index 37654cdfd7abcf..00000000000000 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ /dev/null @@ -1,10 +0,0 @@ -Thanks for taking the time to contribute to Git! Please be advised that the -Git community does not use github.com for their contributions. Instead, we use -a mailing list (git@vger.kernel.org) for code submissions, code reviews, and -bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/) -to conveniently send your Pull Requests commits to our mailing list. - -For a single-commit pull request, please *leave the pull request description -empty*: your commit message itself should describe your changes. - -Please read the "guidelines for contributing" linked above! diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md deleted file mode 100644 index e58917c50a96dc..00000000000000 --- a/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,145 +0,0 @@ -# Git Code of Conduct - -This code of conduct outlines our expectations for participants within -the Git community, as well as steps for reporting unacceptable behavior. -We are committed to providing a welcoming and inspiring community for -all and expect our code of conduct to be honored. Anyone who violates -this code of conduct may be banned from the community. - -## Our Pledge - -We as members, contributors, and leaders pledge to make participation in our -community a harassment-free experience for everyone, regardless of age, body -size, visible or invisible disability, ethnicity, sex characteristics, gender -identity and expression, level of experience, education, socio-economic status, -nationality, personal appearance, race, religion, or sexual identity -and orientation. - -We pledge to act and interact in ways that contribute to an open, welcoming, -diverse, inclusive, and healthy community. - -## Our Standards - -Examples of behavior that contributes to a positive environment for our -community include: - -* Demonstrating empathy and kindness toward other people -* Being respectful of differing opinions, viewpoints, and experiences -* Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes, - and learning from the experience -* Focusing on what is best not just for us as individuals, but for the - overall community - -Examples of unacceptable behavior include: - -* The use of sexualized language or imagery, and sexual attention or - advances of any kind -* Trolling, insulting or derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or email - address, without their explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting - -## Enforcement Responsibilities - -Community leaders are responsible for clarifying and enforcing our standards of -acceptable behavior and will take appropriate and fair corrective action in -response to any behavior that they deem inappropriate, threatening, offensive, -or harmful. - -Community leaders have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are -not aligned to this Code of Conduct, and will communicate reasons for moderation -decisions when appropriate. - -## Scope - -This Code of Conduct applies within all community spaces, and also applies when -an individual is officially representing the community in public spaces. -Examples of representing our community include using an official e-mail address, -posting via an official social media account, or acting as an appointed -representative at an online or offline event. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported to the community leaders responsible for enforcement at -git@sfconservancy.org, or individually: - - - Ævar Arnfjörð Bjarmason - - Christian Couder - - Junio C Hamano - - Taylor Blau - -All complaints will be reviewed and investigated promptly and fairly. - -All community leaders are obligated to respect the privacy and security of the -reporter of any incident. - -## Enforcement Guidelines - -Community leaders will follow these Community Impact Guidelines in determining -the consequences for any action they deem in violation of this Code of Conduct: - -### 1. Correction - -**Community Impact**: Use of inappropriate language or other behavior deemed -unprofessional or unwelcome in the community. - -**Consequence**: A private, written warning from community leaders, providing -clarity around the nature of the violation and an explanation of why the -behavior was inappropriate. A public apology may be requested. - -### 2. Warning - -**Community Impact**: A violation through a single incident or series -of actions. - -**Consequence**: A warning with consequences for continued behavior. No -interaction with the people involved, including unsolicited interaction with -those enforcing the Code of Conduct, for a specified period of time. This -includes avoiding interactions in community spaces as well as external channels -like social media. Violating these terms may lead to a temporary or -permanent ban. - -### 3. Temporary Ban - -**Community Impact**: A serious violation of community standards, including -sustained inappropriate behavior. - -**Consequence**: A temporary ban from any sort of interaction or public -communication with the community for a specified period of time. No public or -private interaction with the people involved, including unsolicited interaction -with those enforcing the Code of Conduct, is allowed during this period. -Violating these terms may lead to a permanent ban. - -### 4. Permanent Ban - -**Community Impact**: Demonstrating a pattern of violation of community -standards, including sustained inappropriate behavior, harassment of an -individual, or aggression toward or disparagement of classes of individuals. - -**Consequence**: A permanent ban from any sort of public interaction within -the community. - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], -version 2.0, available at -[https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0]. - -Community Impact Guidelines were inspired by -[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. - -For answers to common questions about this code of conduct, see the FAQ at -[https://www.contributor-covenant.org/faq][FAQ]. Translations are available -at [https://www.contributor-covenant.org/translations][translations]. - -[homepage]: https://www.contributor-covenant.org -[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html -[Mozilla CoC]: https://github.com/mozilla/diversity -[FAQ]: https://www.contributor-covenant.org/faq -[translations]: https://www.contributor-covenant.org/translations - diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc deleted file mode 100644 index c874b208ba6be2..00000000000000 --- a/Documentation/BreakingChanges.adoc +++ /dev/null @@ -1,290 +0,0 @@ -= Upcoming breaking changes - -The Git project aims to ensure backwards compatibility to the best extent -possible. Minor releases will not break backwards compatibility unless there is -a very strong reason to do so, like for example a security vulnerability. - -Regardless of that, due to the age of the Git project, it is only natural to -accumulate a backlog of backwards-incompatible changes that will eventually be -required to keep the project aligned with a changing world. These changes fall -into several categories: - -* Changes to long established defaults. -* Concepts that have been replaced with a superior design. -* Concepts, commands, configuration or options that have been lacking in major - ways and that cannot be fixed and which will thus be removed without any - replacement. - -Explicitly not included in this list are fixes to minor bugs that may cause a -change in user-visible behavior. - -The Git project irregularly releases breaking versions that deliberately break -backwards compatibility with older versions. This is done to ensure that Git -remains relevant, safe and maintainable going forward. The release cadence of -breaking versions is typically measured in multiple years. We had the following -major breaking releases in the past: - -* Git 1.6.0, released in August 2008. -* Git 2.0, released in May 2014. - -We use . release numbers these days, starting from Git 2.0. For -future releases, our plan is to increment in the release number when we -make the next breaking release. Before Git 2.0, the release numbers were -1.. with the intention to increment for "usual" breaking -releases, reserving the jump to Git 2.0 for really large backward-compatibility -breaking changes. - -The intent of this document is to track upcoming deprecations for future -breaking releases. Furthermore, this document also tracks what will _not_ be -deprecated. This is done such that the outcome of discussions document both -when the discussion favors deprecation, but also when it rejects a deprecation. - -Items should have a clear summary of the reasons why we do or do not want to -make the described change that can be easily understood without having to read -the mailing list discussions. If there are alternatives to the changed feature, -those alternatives should be pointed out to our users. - -All items should be accompanied by references to relevant mailing list threads -where the deprecation was discussed. These references use message-IDs, which -can visited via - - https://lore.kernel.org/git/$message_id/ - -to see the message and its surrounding discussion. Such a reference is there to -make it easier for you to find how the project reached consensus on the -described item back then. - -This is a living document as the environment surrounding the project changes -over time. If circumstances change, an earlier decision to deprecate or change -something may need to be revisited from time to time. So do not take items on -this list to mean "it is settled, do not waste our time bringing it up again". - -== Procedure - -Discussing the desire to make breaking changes, declaring that breaking -changes are made at a certain version boundary, and recording these -decisions in this document, are necessary but not sufficient. -Because such changes are expected to be numerous, and the design and -implementation of them are expected to span over time, they have to -be deployable trivially at such a version boundary, prepared over long -time. - -The breaking changes MUST be guarded with the a compile-time switch, -WITH_BREAKING_CHANGES, to help this process. When built with it, -the resulting Git binary together with its documentation would -behave as if these breaking changes slated for the next big version -boundary are already in effect. We also have a CI job to exercise -the work-in-progress version of Git with these breaking changes. - - -== Git 3.0 - -The following subsections document upcoming breaking changes for Git 3.0. There -is no planned release date for this breaking version yet. - -Proposed changes and removals only include items which are "ready" to be done. -In other words, this is not supposed to be a wishlist of features that should -be changed to or replaced in case the alternative was implemented already. - -=== Changes - -* The default hash function for new repositories will be changed from "sha1" - to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays - recommended against in FIPS 140-2 and similar certifications. Furthermore, - there are practical attacks on SHA-1 that weaken its cryptographic properties: -+ - ** The SHAppening (2015). The first demonstration of a practical attack - against SHA-1 with 2^57 operations. - ** SHAttered (2017). Generation of two valid PDF files with 2^63 operations. - ** Birthday-Near-Collision (2019). This attack allows for chosen prefix - attacks with 2^68 operations. - ** Shambles (2020). This attack allows for chosen prefix attacks with 2^63 - operations. -+ -While we have protections in place against known attacks, it is expected -that more attacks against SHA-1 will be found by future research. Paired -with the ever-growing capability of hardware, it is only a matter of time -before SHA-1 will be considered broken completely. We want to be prepared -and will thus change the default hash algorithm to "sha256" for newly -initialized repositories. -+ -An important requirement for this change is that the ecosystem is ready to -support the "sha256" object format. This includes popular Git libraries, -applications and forges. -+ -There is no plan to deprecate the "sha1" object format at this point in time. -+ -Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>, -<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>, -. - -* The default storage format for references in newly created repositories will - be changed from "files" to "reftable". The "reftable" format provides - multiple advantages over the "files" format: -+ - ** It is impossible to store two references that only differ in casing on - case-insensitive filesystems with the "files" format. This issue is common - on Windows and macOS platforms. As the "reftable" backend does not use - filesystem paths to encode reference names this problem goes away. - ** Similarly, macOS normalizes path names that contain unicode characters, - which has the consequence that you cannot store two names with unicode - characters that are encoded differently with the "files" backend. Again, - this is not an issue with the "reftable" backend. - ** Deleting references with the "files" backend requires Git to rewrite the - complete "packed-refs" file. In large repositories with many references - this file can easily be dozens of megabytes in size, in extreme cases it - may be gigabytes. The "reftable" backend uses tombstone markers for - deleted references and thus does not have to rewrite all of its data. - ** Repository housekeeping with the "files" backend typically performs - all-into-one repacks of references. This can be quite expensive, and - consequently housekeeping is a tradeoff between the number of loose - references that accumulate and slow down operations that read references, - and compressing those loose references into the "packed-refs" file. The - "reftable" backend uses geometric compaction after every write, which - amortizes costs and ensures that the backend is always in a - well-maintained state. - ** Operations that write multiple references at once are not atomic with the - "files" backend. Consequently, Git may see in-between states when it reads - references while a reference transaction is in the process of being - committed to disk. - ** Writing many references at once is slow with the "files" backend because - every reference is created as a separate file. The "reftable" backend - significantly outperforms the "files" backend by multiple orders of - magnitude. - ** The reftable backend uses a binary format with prefix compression for - reference names. As a result, the format uses less space compared to the - "packed-refs" file. -+ -Users that get immediate benefit from the "reftable" backend could continue to -opt-in to the "reftable" format manually by setting the "init.defaultRefFormat" -config. But defaults matter, and we think that overall users will have a better -experience with less platform-specific quirks when they use the new backend by -default. -+ -A prerequisite for this change is that the ecosystem is ready to support the -"reftable" format. Most importantly, alternative implementations of Git like -JGit, libgit2 and Gitoxide need to support it. - -* In new repositories, the default branch name will be `main`. We have been - warning that the default name will change since 675704c74dd (init: - provide useful advice about init.defaultBranch, 2020-12-11). The new name - matches the default branch name used in new repositories by many of the - big Git forges. -+ -=== Removals - -* Support for grafting commits has long been superseded by git-replace(1). - Grafts are inferior to replacement refs: -+ - ** Grafts are a local-only mechanism and cannot be shared across - repositories. - ** Grafts can lead to hard-to-diagnose problems when transferring objects - between repositories. -+ -The grafting mechanism has been marked as outdated since e650d0643b (docs: mark -info/grafts as outdated, 2014-03-05) and will be removed. -+ -Cf. <20140304174806.GA11561@sigill.intra.peff.net>. - -* The git-pack-redundant(1) command can be used to remove redundant pack files. - The subcommand is unusably slow and the reason why nobody reports it as a - performance bug is suspected to be the absence of users. We have nominated - the command for removal and have started to emit a user-visible warning in - c3b58472be (pack-redundant: gauge the usage before proposing its removal, - 2020-08-25) whenever the command is executed. -+ -So far there was a single complaint about somebody still using the command, but -that complaint did not cause us to reverse course. On the contrary, we have -doubled down on the deprecation and starting with 4406522b76 (pack-redundant: -escalate deprecation warning to an error, 2023-03-23), the command dies unless -the user passes the `--i-still-use-this` option. -+ -There have not been any subsequent complaints, so this command will finally be -removed. -+ -Cf. , - , - <20230323204047.GA9290@coredump.intra.peff.net>, - -* Support for storing shorthands for remote URLs in "$GIT_COMMON_DIR/branches/" - and "$GIT_COMMON_DIR/remotes/" has been long superseded by storing remotes in - the repository configuration. -+ -The mechanism has originally been introduced in f170e4b39d ([PATCH] fetch/pull: -short-hand notation for remote repositories., 2005-07-16) and was superseded by -6687f8fea2 ([PATCH] Use .git/remote/origin, not .git/branches/origin., -2005-08-20), where we switched from ".git/branches/" to ".git/remotes/". That -commit already mentions an upcoming deprecation of the ".git/branches/" -directory, and starting with a1d4aa7424 (Add repository-layout document., -2005-09-01) we have also marked this layout as deprecated. Eventually we also -started to migrate away from ".git/remotes/" in favor of config-based remotes, -and we have marked the directory as legacy in 3d3d282146 (Documentation: -Grammar correction, wording fixes and cleanup, 2011-08-23) -+ -As our documentation mentions, these directories are unlikely to be used in -modern repositories and most users aren't even aware of these mechanisms. They -have been deprecated for almost 20 years and 14 years respectively, and we are -not aware of any active users that have complained about this deprecation. -Furthermore, the ".git/branches/" directory is nowadays misleadingly named and -may cause confusion as "branches" are almost exclusively used in the context of -references. -+ -These features will be removed. - -* Support for "--stdin" option in the "name-rev" command was - deprecated (and hidden from the documentation) in the Git 2.40 - timeframe, in preference to its synonym "--annotate-stdin". Git 3.0 - removes the support for "--stdin" altogether. - -* The git-whatchanged(1) command has outlived its usefulness more than - 10 years ago, and takes more keystrokes to type than its rough - equivalent `git log --raw`. We have nominated the command for - removal, have changed the command to refuse to work unless the - `--i-still-use-this` option is given, and asked the users to report - when they do so. -+ -The command will be removed. - -* Support for `core.commentString=auto` has been deprecated and will - be removed in Git 3.0. -+ -cf. - -* Support for `core.preferSymlinkRefs=true` has been deprecated and will be - removed in Git 3.0. Writing symbolic refs as symbolic links will be phased - out in favor of using plain files using the textual representation of - symbolic refs. -+ -Symbolic references were initially always stored as a symbolic link. This was -changed in 9b143c6e15 (Teach update-ref about a symbolic ref stored in a -textfile., 2005-09-25), where a new textual symref format was introduced to -store those symbolic refs in a plain file. In 9f0bb90d16 -(core.prefersymlinkrefs: use symlinks for .git/HEAD, 2006-05-02), the Git -project switched the default to use the textual symrefs in favor of symbolic -links. -+ -The migration away from symbolic links has happened almost 20 years ago by now, -and there is no known reason why one should prefer them nowadays. Furthermore, -symbolic links are not supported on some platforms. -+ -Note that only the writing side for such symbolic links is deprecated. Reading -such symbolic links is still supported for now. - -== Superseded features that will not be deprecated - -Some features have gained newer replacements that aim to improve the design in -certain ways. The fact that there is a replacement does not automatically mean -that the old way of doing things will eventually be removed. This section tracks -those features with newer alternatives. - -* The features git-checkout(1) offers are covered by the pair of commands - git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still - widespread, and it is not expected that this will change anytime soon, all - three commands will stay. -+ -This decision may get revisited in case we ever figure out that there are -almost no users of any of the commands anymore. -+ -Cf. , -, -<112b6568912a6de6672bf5592c3a718e@manjaro.org>. diff --git a/README.md b/README.md index 249e92974e7f6f..7d24a04932a33a 100644 --- a/README.md +++ b/README.md @@ -1,72 +1,10 @@ -[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush) +[![Build status](https://github.com/libre-wd-40/git/workflows/CI/badge.svg)](https://github.com/libre-wd-40/git/actions?query=branch%3Amaster+event%3Apush) Git - fast, scalable, distributed revision control system ========================================================= Git with WD-40 applied. -Git is a fast, scalable, distributed revision control system with an -unusually rich command set that provides both high-level operations -and full access to internals. - -Git is an Open Source project covered by the GNU General Public -License version 2 (some parts of it are under different licenses, -compatible with the GPLv2). It was originally written by Linus -Torvalds with help of a group of hackers around the net. - -Please read the file [INSTALL][] for installation instructions. - -Many Git online resources are accessible from -including full documentation and Git related tools. - -See [Documentation/gittutorial.adoc][] to get started, then see -[Documentation/giteveryday.adoc][] for a useful minimum set of commands, and -`Documentation/git-.adoc` for documentation of each command. -If git has been correctly installed, then the tutorial can also be -read with `man gittutorial` or `git help tutorial`, and the -documentation of each command with `man git-` or `git help -`. - -CVS users may also want to read [Documentation/gitcvs-migration.adoc][] -(`man gitcvs-migration` or `git help cvs-migration` if git is -installed). - -The user discussion and development of Git take place on the Git -mailing list -- everyone is welcome to post bug reports, feature -requests, comments and patches to git@vger.kernel.org (read -[Documentation/SubmittingPatches][] for instructions on patch submission -and [Documentation/CodingGuidelines][]). - -Those wishing to help with error message, usage and informational message -string translations (localization l10) should see [po/README.md][] -(a `po` file is a Portable Object file that holds the translations). - -To subscribe to the list, send an email to -(see https://subspace.kernel.org/subscribing.html for details). The mailing -list archives are available at , - and other archival sites. - -Issues which are security relevant should be disclosed privately to -the Git Security mailing list . - -The maintainer frequently sends the "What's cooking" reports that -list the current status of various development topics to the mailing -list. The discussion following them give a good reference for -project status, development direction and remaining tasks. - -The name "git" was given by Linus Torvalds when he wrote the very -first version. He described the tool as "the stupid content tracker" -and the name as (depending on your mood): - - - random three-letter combination that is pronounceable, and not - actually used by any common UNIX command. The fact that it is a - mispronunciation of "get" may or may not be relevant. - - stupid. contemptible and despicable. simple. Take your pick from the - dictionary of slang. - - "global information tracker": you're in a good mood, and it actually - works for you. Angels sing, and a light suddenly fills the room. - - "goddamn idiotic truckload of sh*t": when it breaks - [INSTALL]: INSTALL [Documentation/gittutorial.adoc]: Documentation/gittutorial.adoc [Documentation/giteveryday.adoc]: Documentation/giteveryday.adoc diff --git a/SECURITY.md b/SECURITY.md deleted file mode 100644 index c720c2ae7f9580..00000000000000 --- a/SECURITY.md +++ /dev/null @@ -1,51 +0,0 @@ -# Security Policy - -## Reporting a vulnerability - -Please send a detailed mail to git-security@googlegroups.com to -report vulnerabilities in Git. - -Even when unsure whether the bug in question is an exploitable -vulnerability, it is recommended to send the report to -git-security@googlegroups.com (and obviously not to discuss the -issue anywhere else). - -Vulnerabilities are expected to be discussed _only_ on that -list, and not in public, until the official announcement on the -Git mailing list on the release date. - -Examples for details to include: - -- Ideally a short description (or a script) to demonstrate an - exploit. -- The affected platforms and scenarios (the vulnerability might - only affect setups with case-sensitive file systems, for - example). -- The name and affiliation of the security researchers who are - involved in the discovery, if any. -- Whether the vulnerability has already been disclosed. -- How long an embargo would be required to be safe. - -## Supported Versions - -There are no official "Long Term Support" versions in Git. -Instead, the maintenance track (i.e. the versions based on the -most recently published feature release, also known as ".0" -version) sees occasional updates with bug fixes. - -Fixes to vulnerabilities are made for the maintenance track for -the latest feature release and merged up to the in-development -branches. The Git project makes no formal guarantee for any -older maintenance tracks to receive updates. In practice, -though, critical vulnerability fixes are applied not only to the -most recent track, but to at least a couple more maintenance -tracks. - -This is typically done by making the fix on the oldest and still -relevant maintenance track, and merging it upwards to newer and -newer maintenance tracks. - -For example, v2.24.1 was released to address a couple of -[CVEs](https://cve.mitre.org/), and at the same time v2.14.6, -v2.15.4, v2.16.6, v2.17.3, v2.18.2, v2.19.3, v2.20.2, v2.21.1, -v2.22.2 and v2.23.1 were released. diff --git a/git-gui/README.md b/git-gui/README.md index 948e9250d5a396..b1923de26b6284 100644 --- a/git-gui/README.md +++ b/git-gui/README.md @@ -39,136 +39,3 @@ make install ``` You probably need to have root/admin permissions to install. - -# Contributing - -The project is currently maintained by Johannes Sixt at -https://github.com/j6t/git-gui. Even though the project is hosted at -GitHub, the development does not happen over GitHub Issues and Pull Requests. -Instead, an email based workflow is used. The Git mailing list -[git@vger.kernel.org](mailto:git@vger.kernel.org) is where the patches are -discussed and reviewed. - -More information about the Git mailing list and instructions to subscribe can -be found [here](https://git.wiki.kernel.org/index.php/GitCommunity). - -## Sending your changes - -Since the development happens over email, you need to send in your commits in -text format. Commits can be converted to emails via the two tools provided by -Git: `git-send-email` and `git-format-patch`. - -You can use `git-format-patch` to generate patches in mbox format from your -commits that can then be sent via email. Let's say you are working on a branch -called 'foo' that was created on top of 'master'. You can run: - -``` -git format-patch -o output_dir master..foo -``` - -to convert all the extra commits in 'foo' into a set of patches saved in the -folder `output_dir`. - -If you are sending multiple patches, it is recommended to include a cover -letter. A cover letter is an email explaining in brief what the series is -supposed to do. A cover letter template can be generated by passing -`--cover-letter` to `git-format-patch`. - -After you send your patches, you might get a review suggesting some changes. -Make those changes, and re-send your patch(es) in reply to the first patch of -your initial version. Also please mention the version of the patch. This can be -done by passing `-v X` to `git-format-patch`, where 'X' is the version number -of the patch(es). - -### Using git-send-email - -You can use `git-send-email` to send patches generated via `git-format-patch`. -While you can directly send patches via `git-send-email`, it is recommended -that you first use `git-format-patch` to generate the emails, audit them, and -then send them via `git-send-email`. - -A pretty good guide to configuring and using `git-send-email` can be found -[here](https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/). - -### Using your email client - -If your email client supports sending mbox format emails, you can use -`git-format-patch` to get an mbox file for each commit, and then send them. If -there is more than one patch in the series, then all patches after the first -patch (or the cover letter) need to be sent as replies to the first. -`git-send-email` does this by default. - -### Using GitGitGadget - -Since some people prefer a GitHub pull request based workflow, they can use -[GitGitGadget](https://gitgitgadget.github.io/) to send in patches. The tool -was originally written for sending patches to the Git project, but it now also -supports sending patches for git-gui. - -Instructions for using GitGitGadget to send git-gui patches, courtesy of -Johannes Schindelin: - -If you don't already have a fork of the [git/git](https://github.com/git/git) -repo, you need to make one. Then clone your fork: - -``` -git clone https://github.com//git -``` - -Then add GitGitGadget as a remote: - -``` -git remote add gitgitgadget https://github.com/gitgitgadget/git -``` - -Then fetch the git-gui branch: - -``` -git fetch gitgitgadget git-gui/master -``` - -Then create a new branch based on git-gui/master: - -``` -git checkout -b git-gui/master -``` - -Make whatever commits you need to, push them to your fork, and then head over -to https://github.com/gitgitgadget/git/pulls and open a Pull Request targeting -git-gui/master. - -GitGitGadget will welcome you with a (hopefully) helpful message. - -## Signing off - -You need to sign off your commits before sending them to the list. You can do -that by passing the `-s` option to `git-commit`. You can also use the "Sign -Off" option in Git GUI. - -A sign-off is a simple 'Signed-off-by: A U Thor \' line at -the end of the commit message, after your explanation of the commit. - -A sign-off means that you are legally allowed to send the code, and it serves -as a certificate of origin. More information can be found at -[developercertificate.org](https://developercertificate.org/). - -## Responding to review comments - -It is quite likely your patches will get review comments. Those comments are -sent on the Git mailing list as replies to your patch, and you will usually be -Cc'ed in those replies. - -You are expected to respond by either explaining your code further to convince -the reviewer what you are doing is correct, or acknowledge the comments and -re-send the patches with those comments addressed. - -Some tips for those not familiar with communication on a mailing list: - -- Use only plain text emails. No HTML at all. -- Wrap lines at around 75 characters. -- Do not send attachments. If you do need to send some files, consider using a - hosting service, and paste the link in your email. -- Do not [top post](http://www.idallen.com/topposting.html). -- Always "reply all". Keep all correspondents and the list in Cc. If you reply - directly to a reviewer, and not Cc the list, other people would not be able - to chime in. diff --git a/gitk-git/README.md b/gitk-git/README.md index 2e307463c61d63..ef65b64c2d25f3 100644 --- a/gitk-git/README.md +++ b/gitk-git/README.md @@ -25,8 +25,6 @@ gitk branch-name gitk v1.0..v2.0 ``` -For more usage examples and options, see the [gitk manual](https://git-scm.com/docs/gitk). - Building ======== @@ -67,27 +65,3 @@ meson install -C builddir Both build systems will handle setting the correct Tcl/Tk interpreter path and installing translation files. - -Contributing -============ - -Contributions are welcome! The preferred method for submitting patches -is via email to the Git mailing list, as this allows for more thorough -review and broader community feedback. However, GitHub pull requests -are also accepted. - -All commits must be signed off (use `git commit --signoff`) and should -have commit messages prefixed with `gitk:`. - -Email Patches -------------- - -Send patches to git@vger.kernel.org and CC j6t@kdbg.org. See the Git -project's [patch submission guidelines](https://git-scm.com/docs/SubmittingPatches) -for detailed instructions on creating and sending patches. - -License -======= - -Gitk is distributed under the GNU General Public License, either -version 2, or (at your option) any later version. diff --git a/po/README.md b/po/README.md deleted file mode 100644 index ec08aa24add4e3..00000000000000 --- a/po/README.md +++ /dev/null @@ -1,460 +0,0 @@ -# Core GIT Translations - -This directory holds the translations for the core of Git. This document -describes how you can contribute to the effort of enhancing the language -coverage and maintaining the translation. - -The localization (l10n) coordinator, Jiang Xin , -coordinates our localization effort in the l10n coordinator repository: - - https://github.com/git-l10n/git-po/ - -We will use XX as an alias to refer to the language translation code in -the following paragraphs, for example we use "po/XX.po" to refer to the -translation file for a specific language. But this doesn't mean that -the language code has only two letters. The language code can be in one -of two forms: "ll" or "ll\_CC". Here "ll" is the ISO 639 two-letter -language code and "CC" is the ISO 3166 two-letter code for country names -and subdivisions. For example: "de" for German language code, "zh\_CN" -for Simplified Chinese language code. - - -## Contributing to an existing translation - -As a contributor for a language XX, you should first check TEAMS file in -this directory to see whether a dedicated repository for your language XX -exists. Fork the dedicated repository and start to work if it exists. - -Sometime, contributors may find that the translations of their Git -distributions are quite different with the translations of the -corresponding version from Git official. This is because some Git -distributions (such as from Ubuntu, etc.) have their own l10n workflow. -For this case, wrong translations should be reported and fixed through -their workflows. - - -## Creating a new language translation - -If you are the first contributor for the language XX, please fork this -repository, prepare and/or update the translated message file "po/XX.po" -(described later), and ask the l10n coordinator to pull your work. - -If there are multiple contributors for the same language, please first -coordinate among yourselves and nominate the team leader for your -language, so that the l10n coordinator only needs to interact with one -person per language. - - -## Translation Process Flow - -The overall data-flow looks like this: - - +-------------------+ +------------------+ - | Git source code | ----(2)---> | L10n coordinator | - | repository | <---(5)---- | repository | - +-------------------+ +------------------+ - | | ^ - (1) (3) (4) - V v | - +----------------------------------+ - | Language Team XX | - +----------------------------------+ - -- Translatable strings are marked in the source file. -- Language teams can start translation iterations at any time, even - before the l10n window opens: - - + Pull from the master branch of the source (1) - + Update the message file by running "make po-update PO\_FILE=po/XX.po" - + Translate the message file "po/XX.po" - -- The L10n coordinator pulls from source and announces the l10n window - open (2) -- Language team pulls from the l10n coordinator, starts another - translation iteration against the l10n coordinator's tree (3) - - + Run "git pull --rebase" from the l10n coordinator - + Update the message file by running "make po-update PO\_FILE=po/XX.po" - + Translate the message file "po/XX.po" - + Squash trivial l10n git commits using "git rebase -i" - -- Language team sends pull request to the l10n coordinator (4) -- L10n coordinator checks and merges -- L10n coordinator asks the result to be pulled (5). - - -## Dynamically generated POT files - -POT files are templates for l10n contributors to create or update their -translation files. We used to have the "po/git.pot" file which was -generated by the l10n coordinator, but this file had been removed from -the tree. - -The two POT files "po/git.pot" and "po/git-core.pot" can be created -dynamically when necessary. - -L10n contributors use "po/git.pot" to prepare translations for their -languages, but they are not expected to modify it. The "po/git.pot" file -can be generated manually with the following command: - -```shell -make po/git.pot -``` - -The "po/git-core.pot" file is the template for core translations. A core -translation is the minimum set of work necessary to complete a -translation of a new language. Since there are more than 5000 messages -in the full set of template message file "po/git.pot" that need to be -translated, this is not a piece of cake for new language contributors. - -The "core" template file "po/git-core.pot" can be generated manually -by running: - -```shell -make po/git-core.pot -``` - - -## Initializing a "XX.po" file - -(This is done by the language teams). - -If your language XX does not have translated message file "po/XX.po" yet, -you add a translation for the first time by running: - -```shell -make po-init PO_FILE=po/XX.po -``` - -where XX is the locale, e.g. "de", "is", "pt\_BR", "zh\_CN", etc. - -The newly generated message file "po/XX.po" is based on the core pot -file "po/git-core.pot", so it contains only a minimal set of messages -and it's a good start for a new language contribution. - -Once you are done testing the translation (see below), commit the result -and ask the l10n coordinator to pull from you. - - -## Updating a "XX.po" file - -(This is done by the language teams). - -If you are replacing translation strings in an existing "XX.po" file to -improve the translation, just edit the file. - -If you want to find new translatable strings in source files of upstream -repository and propagate them to your "po/XX.po", run command: - -```shell -make po-update PO_FILE=po/XX.po -``` - -It will: - -- Call "make po/git.pot" to generate new "po/git.pot" file -- Call "msgmerge --add-location --backup=off -U po/XX.po po/git.pot" - to update your "po/XX.po" -- The "--add-location" option for msgmerge will add location lines, - and these location lines will help translation tools to locate - translation context easily. - -Once you are done testing the translation (see below), it's better -to commit a location-less "po/XX.po" file to save repository space -and make a user-friendly patch for review. - -To save a location-less "po/XX.po" automatically in repository, you -can: - -First define a new attribute for "po/XX.po" by appending the following -line in ".git/info/attributes": - -``` -/po/XX.po filter=gettext-no-location -``` - -Then define the driver for the "gettext-no-location" clean filter to -strip out both filenames and locations from the contents as follows: - -```shell -git config --global filter.gettext-no-location.clean \ - "msgcat --no-location -" -``` - -For users who have gettext version 0.20 or higher, it is also possible -to define a clean filter to preserve filenames but not locations: - -```shell -git config --global filter.gettext-no-location.clean \ - "msgcat --add-location=file -" -``` - -You're now ready to ask the l10n coordinator to pull from you. - - -## Fuzzy translation - -Fuzzy translation is a translation marked by comment "fuzzy" to let you -know that the translation is out of date because the "msgid" has been -changed. A fuzzy translation will be ignored when compiling using "msgfmt". -Fuzzy translation can be marked by hands, but for most cases they are -marked automatically when running "msgmerge" to update your "XX.po" file. - -After fixing the corresponding translation, you must remove the "fuzzy" -tag in the comment. - - -## Testing your changes - -(This is done by the language teams, after creating or updating "XX.po" file). - -Before you submit your changes go back to the top-level and do: - -```shell -make -``` - -On systems with GNU gettext (i.e. not Solaris) this will compile your -changed PO file with `msgfmt --check`, the --check option flags many -common errors, e.g. missing printf format strings, or translated -messages that deviate from the originals in whether they begin/end -with a newline or not. - -L10n coordinator will check your contributions using a helper program -(see "PO helper" section below): - -```shell -git-po-helper check-po po/XX.po -git-po-helper check-commits -``` - - -## Marking strings for translation - -(This is done by the core developers). - -Before strings can be translated they first have to be marked for -translation. - -Git uses an internationalization interface that wraps the system's -gettext library, so most of the advice in your gettext documentation -(on GNU systems `info gettext` in a terminal) applies. - -General advice: - -- Don't mark everything for translation, only strings which will be - read by humans (the porcelain interface) should be translated. - - The output from Git's plumbing utilities will primarily be read by - programs and would break scripts under non-C locales if it was - translated. Plumbing strings should not be translated, since - they're part of Git's API. - -- Adjust the strings so that they're easy to translate. Most of the - advice in `info '(gettext)Preparing Strings'` applies here. - -- Strings referencing numbers of items may need to be split into singular and - plural forms; see the Q\_() wrapper in the C sub-section below for an - example. - -- If something is unclear or ambiguous you can use a "TRANSLATORS" - comment to tell the translators what to make of it. These will be - extracted by xgettext(1) and put in the "po/\*.po" files, e.g. from - git-am.sh: - - ```shell - # TRANSLATORS: Make sure to include [y], [n], [e], [v] and [a] - # in your translation. The program will only accept English - # input at this point. - gettext "Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all " - ``` - - Or in C, from builtin/revert.c: - - ```c - /* TRANSLATORS: %s will be "revert" or "cherry-pick" */ - die(_("%s: Unable to write new index file"), action_name(opts)); - ``` - -We provide wrappers for C, Shell and Perl programs. Here's how they're -used: - - -### C - -Include builtin.h at the top, it'll pull in gettext.h, which -defines the gettext interface. Consult with the list if you need to -use gettext.h directly. - -The C interface is a subset of the normal GNU gettext -interface. We currently export these functions: - -- \_() - - Mark and translate a string. E.g.: - - ```c - printf(_("HEAD is now at %s"), hex); - ``` - -- Q\_() - - Mark and translate a plural string. E.g.: - - ```c - printf(Q_("%d commit", "%d commits", number_of_commits)); - ``` - - This is just a wrapper for the ngettext() function. - -- N\_() - - A no-op pass-through macro for marking strings inside static - initializations, e.g.: - - ```c - static const char *reset_type_names[] = { - N_("mixed"), N_("soft"), N_("hard"), N_("merge"), N_("keep"), NULL - }; - ``` - - And then, later: - - ```c - die(_("%s reset is not allowed in a bare repository"), - _(reset_type_names[reset_type])); - ``` - - Here `_()` couldn't have statically determined what the translation - string will be, but since it was already marked for translation - with `N_()` the look-up in the message catalog will succeed. - - -### Shell - -The Git gettext shell interface is just a wrapper for -gettext.sh. Import it right after git-sh-setup like this: - -```shell -. git-sh-setup -. git-sh-i18n -``` - -And then use the `gettext` or `eval_gettext` functions: - -```shell -# For constant interface messages: -gettext "A message for the user"; echo - -# To interpolate variables: -details="oh noes" -eval_gettext "An error occurred: \$details"; echo -``` - -In addition we have wrappers for messages that end with a trailing -newline. I.e. you could write the above as: - -```shell -# For constant interface messages: -gettextln "A message for the user" - -# To interpolate variables: -details="oh noes" -eval_gettextln "An error occurred: \$details" -``` - -More documentation about the interface is available in the GNU info -page: `info '(gettext)sh'`. Looking at git-am.sh (the first shell -command to be translated) for examples is also useful: - -```shell -git log --reverse -p --grep=i18n git-am.sh -``` - - -### Perl - -The Git::I18N module provides a limited subset of the -Locale::Messages functionality, e.g.: - -```perl -use Git::I18N; -print __("Welcome to Git!\n"); -printf __("The following error occurred: %s\n"), $error; -``` - -Run `perldoc perl/Git/I18N.pm` for more info. - - -## Testing marked strings - -Git's tests are run under `LANG=C LC_ALL=C`. So the tests do not need be -changed to account for translations as they're added. - - -## PO helper - -To make the maintenance of "XX.po" easier, the l10n coordinator and l10n -team leaders can use a helper program named "git-po-helper". It is a -wrapper to gettext suite, specifically written for the purpose of Git -l10n workflow. - -To build and install the helper program from source, see -[git-po-helper/README][]. - - -## Conventions - -There are some conventions that l10n contributors must follow: - -- The subject of each l10n commit should be prefixed with "l10n: ". - -- Do not use non-ASCII characters in the subject of a commit. - -- The length of commit subject (first line of the commit log) should - be no more than 50 characters, and the length of other lines of the - commit log should be no more than 72 characters. - -- Add "Signed-off-by" trailer to your commit log, like other commits - in Git. You can automatically add the trailer by committing with - the following command: - - ```shell - git commit -s - ``` - -- Check syntax with "msgfmt" or the following command before creating - your commit: - - ```shell - git-po-helper check-po - ``` - -- Squash trivial commits to make history clear. - -- DO NOT edit files outside "po/" directory. - -- Other subsystems ("git-gui", "gitk", and Git itself) have their - own workflow. See [Documentation/SubmittingPatches][] for - instructions on how to contribute patches to these subsystems. - - -To contribute for a new l10n language, contributor should follow -additional conventions: - -- Initialize proper filename of the "XX.po" file conforming to - iso-639 and iso-3166. - -- Must complete a minimal translation based on the "Core - translation". See that section above. - -- Add a new entry in the "po/TEAMS" file with proper format, and check - the syntax of "po/TEAMS" by running the following command: - - ```shell - git-po-helper team --check - ``` - - -[git-po-helper/README]: https://github.com/git-l10n/git-po-helper#readme -[Documentation/SubmittingPatches]: Documentation/SubmittingPatches