[pull] master from git:master#82
Merged
pull[bot] merged 22 commits intoturkdevops:masterfrom Jul 25, 2025
Merged
Conversation
* ss/revert-builtin-bswap-stuff: Revert "bswap.h: add support for built-in bswap functions"
As well as receiving the config key and value, config callbacks also receive a "struct key_value_info" containing information about the source of the key-value pair. Accessing the "path" field of this struct from a callback passed to repo_config() results in a use-after-free. This happens because repo_config() first populates a configset by calling config_with_options() and then iterates over the configset with the callback passed by the caller. When the configset is constructed it takes a shallow copy of the "struct key_value_info" for each config setting. This leads to the use-after-free as the "path" member is freed before config_with_options() returns. We could fix this by interning the "path" field as we do for the "filename" field but the "path" field is not actually needed. It is populated with a copy of the "path" field from "struct config_source". That field was added in d14d424 (config: disallow relative include paths from blobs, 2014-02-19) to distinguish between relative include directives in files and those in blobs. However, since 1b8132d (i18n: config: unfold error messages marked for translation, 2016-07-28) we can differentiate these by looking at the "origin_type" field in "struct key_value_info". So let's remove the "path" members from "struct config_source" and "struct key_value_info" and instead use a combination of the "filename" and "origin_type" fields to determine the absolute path of relative includes. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
$GIT_TEST_INSTALLED can be set to use an "installed" git instead of the one from $GIT_BUILD_DIR. This is used by my company's internal test infrastructure, and not using $GIT_TEST_INSTALLED when querying the default hash meant that the tests were failing because the hash was effectively set to the empty string (since git didn't execute). In the two places we attempt to detect/execute git itself prior to overriding everything and putting it in $PATH, use identical logic for identifying the git binary to execute. This also has the effect of including the $X suffix when querying the default hash, but that's not strictly necessary. You don't need to specify .exe when running a binary on Windows, just when testing whether it exists or not. Signed-off-by: Kyle Lippincott <spectral@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The __BYTE_ORDER__ define is provided by gcc (since ~v4.6), clang (since ~v3.2) and icc (since ~16.0.3). The __BYTE_ORDER and BYTE_ORDER macros are libc specific and are not available on all supported platforms such as mingw. Add support for the __BYTE_ORDER__ macro as a fallback. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Microsoft Visual C++ (MSVC) compiler (as of Visual Studio 2022 version 17.13.6) does not define __BYTE_ORDER__ and its C-library does not define __BYTE_ORDER. The compiler is supported only on arm64 and x86 which are all little endian. Define GIT_BYTE_ORDER on msvc as little endian to avoid further checks. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The ntohl and htonl macros are redefined because the provided macros were not always optimal. Sometimes it was a function call, sometimes it was a macro which did the shifting. Using the 'bswap' opcode on x86 provides probably better performance than performing the shifting. These macros are only overwritten on x86 if the "optimized" version is available. The ntohll and htonll macros are not available on every platform (at least glibc does not provide them) which means they need to be defined once the endianness of the system is determined. In order to get a more symmetrical setup, redfine the macros once the endianness of the system has been determined. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On x86 the bswap32/64 macro is implemented based on the x86 opcode which performs the required shifting in just one opcode. The other CPUs fallback to the generic shifting as implemented by default_swab32() and default_bswap64() if needed. I've been looking at how good a compiler is at recognizing the default shift and emitting an optimized operation: - x86, arm64 msvc v19.20 default_swab32() optimized default_bswap64() shifts _byteswap_uint64() optimized - x86, arm64 msvc v19.37 default_swab32() optimized default_bswap64() optimized _byteswap_uint64() optimized - arm64, gcc-4.9.4: optimized - x86-64, gcc-4.4.7: shifts - x86-64, gcc-4.5.3: optimized - x86-64, clang-3.0: optimized Given that gcc-4.5 and clang-3.0 are fairly old, any recent compiler should recognize the shift. Remove the optimized x86 version and rely on the compiler. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The compiler is in general able to recognize the endian shift and replace it with an optimized opcode if possible. On certain architectures such as RiscV or MIPS the situation can get complicated. They don't provide an optimized opcode and masking the "higher" bits may required loading a constant which needs shifting. This causes the compiler to emit a lot of instructions for the operation. The provided builtin directive on these architecture calls a function which does the operation instead of emitting the code for operation. Bring back the change from commit 6547d1c (bswap.h: add support for built-in bswap functions, 2025-04-23). The bswap32/64 macro can now be defined unconditionally so it won't regress on big endian architectures. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 837f637 ("meson.build: correct setting of GIT_EXEC_PATH", 2025-05-19) corrected the GIT_EXEC_PATH build setting, but then forgot to update the installation path for the library executables. This causes a regression when attempting to execute commands, after installing to a non-standard location (reported here[1]): $ meson -Dprefix=/tmp/git -Dlibexecdir=libexec-different build $ meson install $ /tmp/git/bin/git --exec-path /tmp/git/libexec-different $ /tmp/git/bin/git daemon git: 'daemon' is not a git command. See 'git --help' In order to fix the issue, use the 'git_exec_path' variable (calculated while processing -Dlibexecdir) as the 'install_dir' field during the installation of the library executables. [1]: <66fd343a-1351-4350-83eb-c797e47b7693@gmail.com> Reported-by: irecca.kun@gmail.com Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit bf5ce43 ("l10n: Add full Irish translation (ga.po)", 2025-05-16) added a new translation to git. In a make build, new 'po' files (ga.po in this case) are added to the build automatically using a wildcard pattern. In a meson build you have to add the language code ('ga') to a list explicitly to have it included in the build. In order to include the new translation in the meson build, add the 'ga' language code to the list of translations in the 'po/meson.build' file. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our submission guidelines require people to use their real name, but this is not always suitable for various reasons. For people who are transgender or non-binary and are transitioning or who think they might want to transition, it can be a major obstacle and cause major discomfort to require the use of their real name. This is made worse by the fact that Git provides no way to change names built into history, so the use of a deadname is forever. Our code of conduct states that we "pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community," and changing this policy is one way we can improve things for contributors. In addition, there are some developers who are so widely known pseudonymously that they have a Wikipedia page with their handle and no real name. It would seem silly to reject patches from people who are known and respected in their open-source community just because they don't wish to share a real name. There are also other good reasons why people might operate pseudonymously: because they or their family members are well known and they wish to protect their privacy, because of current or past harassment or retaliation or fear of that happening in the future, or because of concerns about unwanted attention from government officials or other authority figures. As much as possible, we want to welcome contributions from anyone who is willing to participate positively in our community without having them worry about their safety or privacy. In all of these cases, we should allow people to proceed using a preferred name or pseudonymously if, in their best judgment, that's the right thing to do. State that it is common to use a real name but explicitly mention that contributors who are not comfortable doing so or prefer to operate pseudonymously or under a preferred name can proceed otherwise, provided the name is distinctive, identifying, and not misleading. For instance, using U+2060 (WORD JOINER) as one's ID would likely be distinctive but not identifying, since most people would have trouble reading it due to its zero-width nature. We prohibit identities which are misleading, since our goal is to create a community which works together with a common goal, and misleading or deceiving others is not conducive to good community or compatible with our code of conduct, nor is it compatible with making a legal assertion about the provenance of one's code. Explicitly prohibit anonymous contributions to ensure that we have some line of provenance to a known (if pseudonymous) author who might be able to respond to questions about it. Explain that this is the reason we have this policy to help contributors understand the rationale better. Use "some form of your real name" since some current contributors use shortened forms of their name or use initials, which have always been considered acceptable. This helps guide people who would be fine using their real name but have misconfigured `user.name` thinking it is intended to be a username or is used for authentication (despite our documentation to the contrary), but also allows for a variety of circumstances where the contributor would feel more comfortable not doing so. Note that this policy is the same as that of the Linux kernel[0] and the CNCF[1], as well as many smaller projects. The Linux kernel patch was Acked-by one of the Linux Foundation's lawyers, Michael Dolan, so it appears these changes have had legal review. Additionally, retain the section header ID for ease of linking across versions. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330 [1] https://github.com/cncf/foundation/blob/659fd32c86dc/dco-guidelines.md Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have had a test balloon for C99's bool type since 8277dbe (git-compat-util: convert skip_{prefix,suffix}{,_mem} to bool, 2023-12-16). As we've had it over 18 months without any complaints let's declare it a success. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 8277dbe (git-compat-util: convert skip_{prefix,suffix}{,_mem} to bool, 2023-12-16) a number of our string predicates have been returning bool instead of int. Now that we've declared that experiment a success, let's convert the return type of the case-independent skip_iprefix() and skip_iprefix_mem() functions to match the return type of their case-dependent equivalents. Returning bool instead of int makes it clear that these functions are predicates. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that the string predicates defined in git-compat-util.h all
return bool let's convert the return type of the string predicates
in strbuf.{c,h} to match them.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Declare weather-balloon we raised for "bool" type 18 months ago a success and officially allow using the type in our codebase. * pw/adopt-c99-bool-officially: strbuf: convert predicates to return bool git-compat-util: convert string predicates to return bool CodingGuidelines: allow the use of bool
GIT_TEST_INSTALLED was not honored in the recent topic related to SHA256 hashes, which has been corrected. * kl/test-installed-fix: test-lib: respect GIT_TEST_INSTALLED when querying default hash
Remove a redundant member from kvi struct. * pw/config-kvi-remove-path: config: remove unneeded struct field
Clean-up compat/bswap.h mess. * ss/compat-bswap-revamp: bswap.h: provide a built-in based version of bswap32/64 if possible bswap.h: remove optimized x86 version of bswap32/64 bswap.h: always overwrite ntohl/ ntohll macros bswap.h: define GIT_LITTLE_ENDIAN on msvc as little endian bswap.h: add support for __BYTE_ORDER__
Meson-based build did not handle libexecdir setting correctly, which has been corrected. * rj/meson-libexecdir-fix: po/meson.build: add missing 'ga' language code meson: fix installation when -Dlibexexdir is set
Document that we do not require "real" name when signing your patches off. * bc/contribution-under-non-real-names: SubmittingPatches: allow non-real name contributions
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.3)
Can you help keep this open source service alive? 💖 Please sponsor : )