summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-44/+41
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the second of multiple changes to git-worktree.txt, restricted to the COMMANDS section. There is some language around the movement of "the working tree of a linked worktree" which is used once, but the remaining uses are left as just moving "a linked worktree" for brevity. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: use 'worktree' over 'working tree'Libravatar Derrick Stolee1-23/+27
It is helpful to distinguish between a 'working tree' and a 'worktree'. A worktree contains a working tree plus additional metadata. This metadata includes per-worktree refs and worktree-specific config. This is the first of multiple changes to git-worktree.txt, restricted to the DESCRIPTION section. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: extract checkout_worktree()Libravatar Derrick Stolee1-11/+15
The ability to add the --no-checkout flag to 'git worktree' was added in ef2a0ac9a0 (worktree: add: introduce --checkout option, 2016-03-29). Recently, we noticed that add_worktree() is rather complicated, so extract the logic for this checkout process to simplify the method. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: extract copy_sparse_checkout()Libravatar Derrick Stolee1-15/+18
This logic was introduced by 5325591 (worktree: copy sparse-checkout patterns and config on add, 2022-02-07), but some feedback came in that the add_worktree() method was already too complex. It is better to extract this logic into a helper method to reduce this complexity. Reported-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: extract copy_filtered_worktree_config()Libravatar Derrick Stolee1-39/+42
This logic was introduced by 5325591 (worktree: copy sparse-checkout patterns and config on add, 2022-02-07), but some feedback came in that the add_worktree() method was already too complex. It is better to extract this logic into a helper method to reduce this complexity. Reported-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-23worktree: combine two translatable messagesLibravatar Derrick Stolee1-2/+4
These two messages differ only by the config key name, which should not be translated. Extract those keys so the messages can be translated from the same string. Reported-by: Jean-Noël AVILA <jn.avila@free.fr> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08config: make git_configset_get_string_tmp() privateLibravatar Derrick Stolee2-3/+2
This method was created in f1de981e8 (config: fix leaks from git_config_get_string_const(), 2020-08-14) but its only use was in the repo_config_get_string_tmp() method, also declared in config.h and implemented in config.c. Since this is otherwise unused and is a very similar implementation to git_configset_get_value(), let's remove this declaration. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08worktree: copy sparse-checkout patterns and config on addLibravatar Derrick Stolee3-10/+142
When adding a new worktree, it is reasonable to expect that we want to use the current set of sparse-checkout settings for that new worktree. This is particularly important for repositories where the worktree would become too large to be useful. This is even more important when using partial clone as well, since we want to avoid downloading the missing blobs for files that should not be written to the new worktree. The only way to create such a worktree without this intermediate step of expanding the full worktree is to copy the sparse-checkout patterns and config settings during 'git worktree add'. Each worktree has its own sparse-checkout patterns, and the default behavior when the sparse-checkout file is missing is to include all paths at HEAD. Thus, we need to have patterns from somewhere, they might as well be the current worktree's patterns. These are then modified independently in the future. In addition to the sparse-checkout file, copy the worktree config file if worktree config is enabled and the file exists. This will copy over any important settings to ensure the new worktree behaves the same as the current one. The only exception we must continue to make is that core.bare and core.worktree should become unset in the worktree's config file. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08sparse-checkout: set worktree-config correctlyLibravatar Derrick Stolee4-28/+30
`git sparse-checkout set/init` enables worktree-specific configuration[*] by setting extensions.worktreeConfig=true, but neglects to perform the additional necessary bookkeeping of relocating `core.bare=true` and `core.worktree` from $GIT_COMMON_DIR/config to $GIT_COMMON_DIR/config.worktree, as documented in git-worktree.txt. As a result of this oversight, these settings, which are nonsensical for secondary worktrees, can cause Git commands to incorrectly consider a worktree bare (in the case of `core.bare`) or operate on the wrong worktree (in the case of `core.worktree`). Fix this problem by taking advantage of the recently-added init_worktree_config() which enables `extensions.worktreeConfig` and takes care of necessary bookkeeping. While at it, for backward-compatibility reasons, also stop upgrading the repository format to "1" since doing so is (unintentionally) not required to take advantage of `extensions.worktreeConfig`, as explained by 11664196ac ("Revert "check_repository_format_gently(): refuse extensions for old repositories"", 2020-07-15). [*] The main reason to use worktree-specific config for the sparse-checkout builtin was to avoid enabling sparse-checkout patterns in one and causing a loss of files in another. If a worktree does not have a sparse-checkout patterns file, then the sparse-checkout logic will not kick in on that worktree. Reported-by: Sean Allred <allred.sean@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08config: add repo_config_set_worktree_gently()Libravatar Derrick Stolee2-3/+40
Some config settings, such as those for sparse-checkout, are likely intended to only apply to one worktree at a time. To make this write easier, add a new config API method, repo_config_set_worktree_gently(). This method will attempt to write to the worktree-specific config, but will instead write to the common config file if worktree config is not enabled. The next change will introduce a consumer of this method. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08worktree: create init_worktree_config()Libravatar Derrick Stolee2-0/+94
Upgrading a repository to use extensions.worktreeConfig is non-trivial. There are several steps involved, including moving some config settings from the common config file to the main worktree's config.worktree file. The previous change updated the documentation with all of these details. Commands such as 'git sparse-checkout set' upgrade the repository to use extensions.worktreeConfig without following these steps, causing some user pain in some special cases. Create a helper method, init_worktree_config(), that will be used in a later change to fix this behavior within 'git sparse-checkout set'. The method is carefully documented in worktree.h. Note that we do _not_ upgrade the repository format version to 1 during this process. The worktree config extension must be considered by Git and third-party tools even if core.repositoryFormatVersion is 0 for historical reasons documented in 11664196ac ("Revert "check_repository_format_gently(): refuse extensions for old repositories"", 2020-07-15). This is a special case for this extension, and newer extensions (such as extensions.objectFormat) still need to upgrade the repository format version. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-08Documentation: add extensions.worktreeConfig detailsLibravatar Derrick Stolee3-5/+45
The extensions.worktreeConfig extension was added in 58b284a (worktree: add per-worktree config files, 2018-10-21) and was somewhat documented in Documentation/git-config.txt. However, the extensions.worktreeConfig value was not specified further in the list of possible config keys. The location of the config.worktree file is not specified, and there are some precautions that should be mentioned clearly, but are only mentioned in git-worktree.txt. Expand the documentation to help users discover the complexities of extensions.worktreeConfig by adding details and cross links in these locations (relative to Documentation/): - config/extensions.txt - git-config.txt - git-worktree.txt The updates focus on items such as * $GIT_DIR/config.worktree takes precedence over $GIT_COMMON_DIR/config. * The core.worktree and core.bare=true settings are incorrect to have in the common config file when extensions.worktreeConfig is enabled. * The sparse-checkout settings core.sparseCheckout[Cone] are recommended to be set in the worktree config. As documented in 11664196ac ("Revert "check_repository_format_gently(): refuse extensions for old repositories"", 2020-07-15), this extension must be considered regardless of the repository format version for historical reasons. A future change will update references to extensions.worktreeConfig within git-sparse-checkout.txt, but a behavior change is needed before making those updates. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24Git 2.35Libravatar Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24Merge branch 'ab/checkout-branch-info-leakfix'Libravatar Junio C Hamano2-3/+13
We added an unrelated sanity checking that leads to a BUG() while plugging a leak, which triggered in a repository with symrefs in the local branch namespace that point at a ref outside. Partially revert the change to avoid triggering the BUG(). * ab/checkout-branch-info-leakfix: checkout: avoid BUG() when hitting a broken repository
2022-01-24Merge tag 'l10n-2.35.0-rnd2' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano11-39598/+36951
l10n-2.35.0-rnd2 * tag 'l10n-2.35.0-rnd2' of git://github.com/git-l10n/git-po: l10n: Update Catalan translation l10n: zh_TW: v2.35.0 round 2 (0 untranslated) l10n: Update Catalan translation l10n: de.po: Update German translation l10n: de.po: Fix translation for "'%s' is aliased to '%s'" l10n: po-id for 2.35 (round 2) l10n: Update Catalan translation l10n: vi(5195t): Update for v2.35.0 round 2 l10n: batch update to fix typo in branch.c l10n: git.pot: v2.35.0 round 2 (1 new, 1 removed) l10n: bg.po: Updated Bulgarian translation (5195t) l10n: zh_CN: v2.35.0 round 1 l10n: fr: v2.35.0 round 1 l10n: zh_TW: v2.35.0 round 1 (1 fuzzy) l10n: po-id for 2.35 (round 1) l10n: sv.po: Update Swedish translation (5196t0f0u) l10n: sv.po: Fix typo l10n: tr: v2.35.0 round 1 l10n: git.pot: v2.35.0 round 1 (126 new, 142 removed)
2022-01-23l10n: Update Catalan translationLibravatar Jordi Mas1-16/+16
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2022-01-22Merge branch 'l10n/zh_TW/220113' of github.com:l10n-tw/git-poLibravatar Jiang Xin1-3115/+3462
* 'l10n/zh_TW/220113' of github.com:l10n-tw/git-po: l10n: zh_TW: v2.35.0 round 2 (0 untranslated) l10n: zh_TW: v2.35.0 round 1 (1 fuzzy)
2022-01-21checkout: avoid BUG() when hitting a broken repositoryLibravatar Junio C Hamano2-3/+13
When 9081a421 (checkout: fix "branch info" memory leaks, 2021-11-16) cleaned up existing memory leaks, we added an unrelated sanity check to ensure that a local branch is truly local and not a symref to elsewhere that dies with BUG() otherwise. This was misguided in two ways. First of all, such a tightening did not belong to a leak-fix patch. And the condition it detected was *not* a bug in our program but a problem in user data, where warning() or die() would have been more appropriate. As the condition is not fatal (the result of computing the local branch name in the code that is involved in the faulty check is only used as a textual label for the commit), let's revert the code to the original state, i.e. strip "refs/heads/" to compute the local branch name if possible, and otherwise leave it NULL. The consumer of the information in merge_working_tree() is prepared to see NULL in there and act accordingly. cf. https://bugzilla.redhat.com/show_bug.cgi?id=2042920 Reported-by: Petr Šplíchal <psplicha@redhat.com> Reported-by: Todd Zullinger <tmz@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-22l10n: zh_TW: v2.35.0 round 2 (0 untranslated)Libravatar Yi-Jyun Pan1-84/+85
Used 1 translation from zh_CN. Thanks to zh_CN translation team! Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2022-01-21l10n: Update Catalan translationLibravatar Jordi Mas1-555/+444
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2022-01-20Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano4-9/+9
"git branch -h" incorrectly said "--track[=direct|inherit]", implying that "--trackinherit" is a valid option, which has been corrected. source: <3de40324bea6a1dd9bca2654721471e3809e87d8.1642538935.git.steadmon@google.com> source: <c3c26192-aee9-185a-e559-b8735139e49c@web.de> * js/branch-track-inherit: branch,checkout: fix --track documentation
2022-01-20branch,checkout: fix --track documentationLibravatar René Scharfe4-9/+9
Document that the accepted variants of the --track option are --track, --track=direct, and --track=inherit. The equal sign in the latter two cannot be replaced with whitespace; in general optional arguments need to be attached firmly to their option. Put "direct" consistently before "inherit", if only for the reasons that the former is the default, explained first in the documentation, and comes before the latter alphabetically. Mention both modes in the short help so that readers don't have to look them up in the full documentation. They are literal strings and thus untranslatable. PARSE_OPT_LITERAL_ARGHELP is inferred due to the pipe and parenthesis characters, so we don't have to provide that flag explicitly. Mention that -t has the same effect as --track and --track=direct. There is no way to specify inherit mode using the short option, because short options generally don't accept optional arguments. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-20l10n: de.po: Update German translationLibravatar Matthias Rüster1-3162/+3168
Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com>
2022-01-20l10n: de.po: Fix translation for "'%s' is aliased to '%s'"Libravatar Jürgen Krämer1-1/+1
The German translation for "'%s' is aliased to '%s'" is incorrect. It switches the order of alias name and alias definition. A better translation would be "'%s' ist ein Alias für '%s'". (Full stop removed intentionally, because the original does not use one either.) Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
2022-01-20Merge branch 'po-id' of github.com:bagasme/git-poLibravatar Jiang Xin1-196/+310
* 'po-id' of github.com:bagasme/git-po: l10n: po-id for 2.35 (round 2)
2022-01-19Git 2.35-rc2Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-19getcwd(mingw): handle the case when there is no cwdLibravatar Johannes Schindelin1-0/+4
A recent upstream topic introduced checks for certain Git commands that prevent them from deleting the current working directory, introducing also a regression test that ensures that commands such as `git version` _can_ run without a current working directory. While technically not possible on Windows via the regular Win32 API, we do run the regression tests in an MSYS2 Bash which uses a POSIX emulation layer (the MSYS2/Cygwin runtime) where a really evil hack _does_ allow to delete a directory even if it is the current working directory. Therefore, Git needs to be prepared for a missing working directory, even on Windows. This issue was not noticed in upstream Git because there was no caller that tried to discover a Git directory with a deleted current working directory in the test suite. But in the microsoft/git fork, we do want to run `pre-command`/`post-command` hooks for every command, even for `git version`, which means that we make precisely such a call. The bug is not in that `pre-command`/`post-command` feature, though, but in `mingw_getcwd()` and needs to be addressed there. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-19l10n: po-id for 2.35 (round 2)Libravatar Bagas Sanjaya1-196/+310
Translate following new components: * advice.c * alias.c * sequencer.c * sparse-index.c * builtin/sparse-checkout.c Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2022-01-19l10n: Update Catalan translationLibravatar Jordi Mas1-4835/+3976
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2022-01-18Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano2-5/+5
"git branch -h" incorrectly said "--track[=direct|inherit]", implying that "--trackinherit" is a valid option, which has been corrected. * js/branch-track-inherit: branch,checkout: fix --track usage strings
2022-01-18Merge branch 'jc/freebsd-without-c99-only-build'Libravatar Junio C Hamano1-0/+5
FreeBSD 13.0 headers have unconditional dependency on C11 language features, and adding -std=gnu99 to DEVELOPER_CFLAGS would just break the developer build. * jc/freebsd-without-c99-only-build: Makefile: FreeBSD cannot do C99-or-below build
2022-01-18branch,checkout: fix --track usage stringsLibravatar Josh Steadmon2-5/+5
As Ævar pointed out in [1], the use of PARSE_OPT_LITERAL_ARGHELP with a list of allowed parameters is not recommended. Both git-branch and git-checkout were changed in d311566 (branch: add flags and config to inherit tracking, 2021-12-20) to use this discouraged combination for their --track flags. Fix this by removing PARSE_OPT_LITERAL_ARGHELP, and changing the arghelp to simply be "mode". Users may discover allowed values in the manual pages. [1]: https://lore.kernel.org/git/220111.86a6g3yqf9.gmgdl@evledraar.gmail.com/ Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18Makefile: FreeBSD cannot do C99-or-below buildLibravatar Junio C Hamano1-0/+5
In "make DEVELOPER=YesPlease" builds, we try to help developers to catch as many potential issues as they can by using -Wall and turning compilation warnings into errors. In the same spirit, we recently started adding -std=gnu99 to their CFLAGS, so that they can notice when they accidentally used language features beyond C99. It however turns out that FreeBSD 13.0 mistakenly uses C11 extension in its system header files regardless of what __STDC_VERSION__ says, which means that the platform (unless we tweak their system headers) cannot be used for this purpose. It seems that -std=gnu99 is only added conditionally even in today's config.mak.dev, so it is fine if we dropped -std=gnu99 from there. Which means that developers on FreeBSD cannot participate in vetting use of features beyond C99, but there are developers on other platforms who will, so it's not too bad. We might want a more "fundamental" fix to make the platform capable of taking -std=gnu99, like working around the use of unconditional C11 extension in its system header files by supplying a set of "replacement" definitions in our header files. We chose not to pursue such an approach for two reasons at this point: (1) The fix belongs to the FreeBSD project, not this project, and such an upstream fix may happen hopefully in a not-too-distant future. (2) Fixing such a bug in system header files and working it around can lead to unexpected breakages (other parts of their system header files may not be expecting to see and do not work well with our "replacement" definitions). This close to the final release of this cycle, we have no time for that. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-17Merge branch 'da/rhel7-lacks-uncompress2-and-c99'Libravatar Junio C Hamano1-0/+5
Adjust build on RHEL 7 to explicitly ask C99 support and use the fallback implementation of uncompress2 we ship. * da/rhel7-lacks-uncompress2-and-c99: build: centos/RHEL 7 ships with an older gcc and zlib
2022-01-17l10n: vi(5195t): Update for v2.35.0 round 2Libravatar Tran Ngoc Quan1-5490/+3119
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2022-01-17l10n: batch update to fix typo in branch.cLibravatar Jiang Xin6-451/+476
In git 2.35 l10n round 1, a space between two words was missing in the message from "branch.c", and it was fixed by commit 68d924e1de (branch: missing space fix at line 313, 2022-01-11). Do a batch update for teams (bg, fr, id, sv, tr and zh_CN) that have already completed their works on l10n round 1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2022-01-17l10n: git.pot: v2.35.0 round 2 (1 new, 1 removed)Libravatar Jiang Xin1-69/+70
Generate po/git.pot from v2.35.0-rc1 for git v2.35.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2022-01-17Merge tag 'v2.35.0-rc1'Libravatar Jiang Xin22-67/+89
Git 2.35-rc1 * tag 'v2.35.0-rc1': Git 2.35-rc1 reftable tests: avoid "int" overflow, use "uint64_t" reftable: avoid initializing structs from structs t1450-fsck: exec-bit is not needed to make loose object writable refs API: use "failure_errno", not "errno" Last minute fixes before -rc1 build: NonStop ships with an older zlib packfile: fix off-by-one error in decoding logic t/gpg: simplify test for unknown key branch: missing space fix at line 313 fmt-merge-msg: prevent use-after-free with signed tags cache.h: drop duplicate `ensure_full_index()` declaration lazyload: use correct calling conventions fetch: fix deadlock when cleaning up lockfiles in async signals
2022-01-16build: centos/RHEL 7 ships with an older gcc and zlibLibravatar David Aguilar1-0/+5
GCC 4.8.5 is the default system compiler on centos7/RHEL7. This version requires -std=c99 to enable c99 support. zlib 1.2.7 on centos7/rhel7 lacks uncompress2(). Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-16l10n: bg.po: Updated Bulgarian translation (5195t)Libravatar Alexander Shopov1-3129/+3145
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2022-01-14Git 2.35-rc1Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-14Merge branch 'js/t1450-making-it-writable-does-not-need-full-posixperm'Libravatar Junio C Hamano1-2/+2
Test fix. * js/t1450-making-it-writable-does-not-need-full-posixperm: t1450-fsck: exec-bit is not needed to make loose object writable
2022-01-14Merge branch 'ab/reftable-build-fixes'Libravatar Junio C Hamano1-13/+13
A few portability tweaks. * ab/reftable-build-fixes: reftable tests: avoid "int" overflow, use "uint64_t" reftable: avoid initializing structs from structs
2022-01-14Merge branch 'ab/refs-errno-cleanup'Libravatar Junio C Hamano2-4/+1
A brown-paper-bag fix on top of a topic that was merged during this cycle. * ab/refs-errno-cleanup: refs API: use "failure_errno", not "errno"
2022-01-13reftable tests: avoid "int" overflow, use "uint64_t"Libravatar Ævar Arnfjörð Bjarmason1-2/+2
Change code added in 1ae2b8cda84 (reftable: add merged table view, 2021-10-07) to consistently use the "uint64_t" type. These "min" and "max" variables get passed in the body of this function to a function whose prototype is: [...] reftable_writer_set_limits([...], uint64_t min, uint64_t max This avoids the following warning on SunCC 12.5 on gcc211.fsffrance.org: "reftable/merged_test.c", line 27: warning: initializer does not fit or is out of range: 0xffffffff Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-13reftable: avoid initializing structs from structsLibravatar Han-Wen Nienhuys1-11/+11
Apparently, the IBM xlc compiler doesn't like this. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-13t1450-fsck: exec-bit is not needed to make loose object writableLibravatar Johannes Sixt1-2/+2
A test case wants to append stuff to a loose object file to ensure that this kind of corruption is detected. To make a read-only loose object file writable with chmod, it is not necessary to also make it executable. Replace the bitmask 755 with the instruction +w to request only the write bit and to also heed the umask. And get rid of a POSIXPERM prerequisite, which is unnecessary for the test. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-13refs API: use "failure_errno", not "errno"Libravatar Ævar Arnfjörð Bjarmason2-4/+1
Fix a logic error in refs_resolve_ref_unsafe() introduced in a recent series of mine to abstract the refs API away from errno. See 96f6623ada0 (Merge branch 'ab/refs-errno-cleanup', 2021-11-29)for that series. In that series introduction of "failure_errno" to refs_resolve_ref_unsafe came in ef18119dec8 (refs API: add a version of refs_resolve_ref_unsafe() with "errno", 2021-10-16). There we'd set "errno = 0" immediately before refs_read_raw_ref(), and then set "failure_errno" to "errno" if errno was non-zero afterwards. Then in the next commit 8b72fea7e91 (refs API: make refs_read_raw_ref() not set errno, 2021-10-16) we started expecting "refs_read_raw_ref()" to set "failure_errno". It would do that if refs_read_raw_ref() failed, but it wouldn't be the same errno. So we might set the "errno" here to any arbitrary bad value, and end up e.g. returning NULL when we meant to return the refname from refs_resolve_ref_unsafe(), or the other way around. Instrumenting this code will reveal cases where refs_read_raw_ref() will fail, and "errno" and "failure_errno" will be set to different values. In practice I haven't found a case where this scary bug changed anything in practice. The reason for that is that we'll not care about the actual value of "errno" here per-se, but only whether: 1. We have an errno 2. If it's one of ENOENT, EISDIR or ENOTDIR. See the adjacent code added in a1c1d8170db (refs_resolve_ref_unsafe: handle d/f conflicts for writes, 2017-10-06) I.e. if we clobber "failure_errno" with "errno", but it happened to be one of those three, and we'll clobber it with another one of the three we were OK. Perhaps there are cases where the difference ended up mattering, but I haven't found them. Instrumenting the test suite to fail if "errno" and "failure_errno" are different shows a lot of failures, checking if they're different *and* one is but not the other is outside that list of three "errno" values yields no failures. But let's fix the obvious bug. We should just stop paying attention to "errno" in refs_resolve_ref_unsafe(). In addition let's change the partial resetting of "errno" in files_read_raw_ref() to happen just before the "return", to ensure that any such bug will be more easily spotted in the future. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-13l10n: zh_CN: v2.35.0 round 1Libravatar Fangyi Zhou1-3703/+3167
- Translate new messages - Translate the word 'cone' instead of leaving it verbatim (in the context of sparse checkout) - Make translations of 'failed to' consistent Signed-off-by: Fangyi Zhou <me@fangyi.io> Reviewed-by: Teng Long <dyroneteng@gmail.com> Reviewed-by: 依云 <lilydjwg@gmail.com> Reviewed-by: Jiang Xin <worldhello.net@gmail.com>
2022-01-13Merge branch 'fr_2.35.0_rnd1' of github.com:jnavila/gitLibravatar Jiang Xin1-3122/+3504
* 'fr_2.35.0_rnd1' of github.com:jnavila/git: l10n: fr: v2.35.0 round 1