summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-02-25object-file API: pass an enum to read_object_with_reference()Libravatar Ævar Arnfjörð Bjarmason7-17/+19
Change the read_object_with_reference() function to take an "enum object_type". It was not prepared to handle an arbitrary "const char *type", as it was itself calling type_from_string(). Let's change the only caller that passes in user data to use type_from_string(), and convert the rest to use e.g. "OBJ_TREE" instead of "tree_type". The "cat-file" caller is not on the codepath that handles"--allow-unknown", so the type_from_string() there is safe. Its use of type_from_string() doesn't functionally differ from that of the pre-image. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file.c: add a literal version of write_object_file_prepare()Libravatar Ævar Arnfjörð Bjarmason1-10/+29
Split off a *_literally() variant of the write_object_file_prepare() function. To do this create a new "hash_object_body()" static helper. We now defer the type_name() call until the very last moment in format_object_header() for those callers that aren't "hash-object --literally". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file API: have hash_object_file() take "enum object_type"Libravatar Ævar Arnfjörð Bjarmason16-34/+41
Change the hash_object_file() function to take an "enum object_type". Since a preceding commit all of its callers are passing either "{commit,tree,blob,tag}_type", or the result of a call to type_name(), the parse_object() caller that would pass NULL is now using stream_object_signature(). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object API: rename hash_object_file_literally() to write_*()Libravatar Ævar Arnfjörð Bjarmason3-7/+7
Before 0c3db67cc81 (hash-object --literally: fix buffer overrun with extra-long object type, 2015-05-04) the hash-object code being changed here called write_sha1_file() to both hash and write a loose object. Before that we'd use hash_sha1_file() to if "-w" wasn't provided, and otherwise call write_sha1_file(). Now we'll always call the same function for both writing. Let's rename it from hash_*_literally() to write_*_literally(). Even though the write_*() might not actually write if HASH_WRITE_OBJECT isn't in "flags", having it be more similar to write_object_file_flags() than hash_object_file(), but carrying a name that would suggest that it's a variant of the latter is confusing. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file API: split up and simplify check_object_signature()Libravatar Ævar Arnfjörð Bjarmason7-28/+38
Split up the check_object_signature() function into that non-streaming version (it accepts an already filled "buf"), and a new stream_object_signature() which will retrieve the object from storage, and hash it on-the-fly. All of the callers of check_object_signature() were effectively calling two different functions, if we go by cyclomatic complexity. I.e. they'd either take the early "if (map)" branch and return early, or not. This has been the case since the "if (map)" condition was added in 090ea12671b (parse_object: avoid putting whole blob in core, 2012-03-07). We can then further simplify the resulting check_object_signature() function since only one caller wanted to pass a non-NULL "buf" and a non-NULL "real_oidp". That "read_loose_object()" codepath used by "git fsck" can instead use hash_object_file() followed by oideq(). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object API users + docs: check <0, not !0 with check_object_signature()Libravatar Ævar Arnfjörð Bjarmason5-6/+8
Change those users of the object API that misused check_object_signature() by assuming it returned any non-zero when the OID didn't match the expected value to check <0 instead. In practice all of this code worked before, but it wasn't consistent with rest of the users of the API. Let's also clarify what the <0 return value means in API docs. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object API docs: move check_object_signature() docs to cache.hLibravatar Ævar Arnfjörð Bjarmason2-6/+6
Move the API documentation for check_object_signature() to cache.h, where its prototype is declared. This is in preparation for adding a companion function. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object API: correct "buf" v.s. "map" mismatch in *.c and *.hLibravatar Ævar Arnfjörð Bjarmason1-5/+5
Change the name of the second argument to check_object_signature() to be "buf" in object-file.c, making it consistent with the prototype in cache.h This fixes an inconsistency that's been with us since 2ade9340262 (Add "check_sha1_signature()" helper function, 2005-04-08), and makes a subsequent commit's diff smaller, as we'll move these API docs to cache.h. While we're at it fix a small grammar error in the documentation, dropping an "an" before "in-core object-data". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file API: have write_object_file() take "enum object_type"Libravatar Ævar Arnfjörð Bjarmason19-33/+33
Change the write_object_file() function to take an "enum object_type" instead of a "const char *type". Its callers either passed {commit,tree,blob,tag}_type and can pass the corresponding OBJ_* type instead, or were hardcoding strings like "blob". This avoids the back & forth fragility where the callers of write_object_file() would have the enum type, and convert it themselves via type_name(). We do have to now do that conversion ourselves before calling write_object_file_prepare(), but those codepaths will be similarly adjusted in subsequent commits. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file API: add a format_object_header() functionLibravatar Ævar Arnfjörð Bjarmason6-11/+35
Add a convenience function to wrap the xsnprintf() command that generates loose object headers. This code was copy/pasted in various parts of the codebase, let's define it in one place and re-use it from there. All except one caller of it had a valid "enum object_type" for us, it's only write_object_file_prepare() which might need to deal with "git hash-object --literally" and a potential garbage type. Let's have the primary API use an "enum object_type", and define a *_literally() function that can take an arbitrary "const char *" for the type. See [1] for the discussion that prompted this patch, i.e. new code in object-file.c that wanted to copy/paste the xsnprintf() invocation. In the case of fast-import.c the callers unfortunately need to cast back & forth between "unsigned char *" and "char *", since format_object_header() ad encode_in_pack_object_header() take different signedness. 1. https://lore.kernel.org/git/211213.86bl1l9bfz.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file API: return "void", not "int" from hash_object_file()Libravatar Ævar Arnfjörð Bjarmason2-11/+11
The hash_object_file() function added in abdc3fc8421 (Add hash_sha1_file(), 2006-10-14) did not have a meaningful return value, and it never has. One was seemingly added to avoid adding braces to the "ret = " assignments being modified here. Let's instead assign "0" to the "ret" variables at the beginning of the relevant functions, and have them return "void". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file.c: split up declaration of unrelated variablesLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Split up the declaration of the "ret" and "re_allocated" variables. It's not our usual style to group variable declarations simply because they share a type, we'd only prefer to do so when the two are closely related (e.g. "int i, j"). This change makes a subsequent and meaningful change's diff smaller. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28Sync with Git 2.35.1Libravatar Junio C Hamano1-0/+6
2022-01-28Name the next one 2.36 to prepare for 2.35.1Libravatar Junio C Hamano2-1/+35
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28Git 2.35.1Libravatar Junio C Hamano3-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-28Merge branch 'en/keep-cwd' into maintLibravatar Junio C Hamano3-2/+30
Fix a regression in 2.35 that roke the use of "rebase" and "stash" in a secondary worktree. * en/keep-cwd: sequencer, stash: fix running from worktree subdir
2022-01-26Merge branch 'en/keep-cwd'Libravatar Junio C Hamano3-2/+30
Fix a regression in 2.35 that roke the use of "rebase" and "stash" in a secondary worktree. * en/keep-cwd: sequencer, stash: fix running from worktree subdir
2022-01-26Start post 2.35 cycleLibravatar Junio C Hamano1-1/+1
The tree is not open for new development yet, but let's mark the beginning of the new cycle before we start merging down regression fix topics. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26sequencer, stash: fix running from worktree subdirLibravatar Elijah Newren3-2/+30
In commits bc3ae46b42 ("rebase: do not attempt to remove startup_info->original_cwd", 2021-12-09) and 0fce211ccc ("stash: do not attempt to remove startup_info->original_cwd", 2021-12-09), we wanted to allow the subprocess to know which directory the parent process was running from, so that the subprocess could protect it. However... When run from a non-main worktree, setup_git_directory() will note that the discovered git directory (/PATH/TO/.git/worktree/non-main-worktree) does not match DEFAULT_GIT_DIR_ENVIRONMENT (see setup_discovered_git_dir()), and decide to set GIT_DIR in the environment. This matters because... Whenever git is run with the GIT_DIR environment variable set, and GIT_WORK_TREE not set, it presumes that '.' is the working tree. So... This combination results in the subcommand being very confused about the working tree. Fix it by also setting the GIT_WORK_TREE environment variable along with setting cmd.dir. A possibly more involved fix we could consider for later would be to make setup.c set GIT_WORK_TREE whenever (a) it discovers both the git directory and the working tree and (b) it decides to set GIT_DIR in the environment. I did not attempt that here as such would be too big of a change for a 2.35.1 release. Test-case-by: Glen Choo <chooglen@google.com> Signed-off-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