As described in https://trojansource.codes/trojan-source.pdf, it is
possible to abuse directional formatting (a feature of Unicode) to
deceive human readers into interpreting code differently from compilers.
For example, an "if ()" expression could be enclosed in a comment, but
rendered as if it was outside of that comment. In effect, this could
fool a reviewer into misinterpreting the code flow as benign when it is
not.
It is highly unlikely that Git's source code wants to contain such
directional formatting in the first place, so let's just disallow it.
Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
Victoria Dye [Thu, 4 Nov 2021 04:01:03 +0000 (04:01 +0000)]
async_die_is_recursing: work around GCC v11.x issue on Fedora
This fix corrects an issue found in the `dockerized(pedantic, fedora)` CI
build, first appearing after the introduction of a new version of the Fedora
docker image version. This image includes a version of `glibc` with the
attribute `__attr_access_none` added to `pthread_setspecific` [1], the
implementation of which only exists for GCC 11.X - the version included in
the Fedora image. The attribute requires that the pointer provided in the
second argument of `pthread_getspecific` must, if not NULL, be a pointer to
a valid object. In the usage in `async_die_is_recursing`, `(void *)1` is not
valid, causing the error.
This fix imitates a workaround added in SELinux [2] by using the pointer to
the static `async_die_counter` itself as the second argument to
`pthread_setspecific`. This guaranteed non-NULL, valid pointer matches the
intent of the current usage while not triggering the build error.
Co-authored-by: Johannes Schindelin <redacted> Signed-off-by: Victoria Dye <redacted> Acked-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jiang Xin [Thu, 4 Nov 2021 00:34:15 +0000 (08:34 +0800)]
Merge branch 'master' of github.com:git/git
* 'master' of github.com:git/git:
Git 2.34-rc1
rebase -i: fix rewording with --committer-date-is-author-date
dir: fix directory-matching bug
gpg-interface: avoid buffer overrun in parse_ssh_output()
gpg-interface: handle missing " with " gracefully in parse_ssh_output()
A few more topics before -rc1
i18n: fix typos found during l10n for git 2.34.0
t5310: drop lib-bundle.sh include
format-patch (doc): clarify --base=auto
gc: perform incremental repack when implictly enabled
fsck: verify multi-pack-index when implictly enabled
fsck: verify commit graph when implicitly enabled
grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data
commit-graph: don't consider "replace" objects with "verify"
commit-graph tests: fix another graph_git_two_modes() helper
commit-graph tests: fix error-hiding graph_git_two_modes() helper
pretty: colorize pattern matches in commit messages
grep: refactor next_match() and match_one_pattern() for external use
Introduce the logical variable GIT_DEFAULT_BRANCH which represents the
the default branch name that will be used by "git init".
Currently this variable is equivalent to
git config init.defaultbranch || 'master'
This however will break if at one point the default branch is changed as
indicated by `default_branch_name_advice` in `refs.c`.
By providing this command ahead of time users of git can make their
code forward-compatible.
Helped-by: Johannes Schindelin <redacted> Helped-by: Eric Sunshine <redacted> Helped-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Thomas Weißschuh <redacted> Signed-off-by: Junio C Hamano <redacted>
Matt Cooper [Tue, 2 Nov 2021 15:46:11 +0000 (15:46 +0000)]
clean/smudge: allow clean filters to process extremely large files
The filter system allows for alterations to file contents when they're
moved between the database and the worktree. We already made sure that
it is possible for smudge filters to produce contents that are larger
than `unsigned long` can represent (which matters on systems where
`unsigned long` is narrower than `size_t`, most notably 64-bit Windows).
Now we make sure that clean filters can _consume_ contents that are
larger than that.
Note that this commit only allows clean filters' _input_ to be larger
than can be represented by `unsigned long`.
This change makes only a very minute dent into the much larger project
to teach Git to use `size_t` instead of `unsigned long` wherever
appropriate.
Helped-by: Johannes Schindelin <redacted> Signed-off-by: Matt Cooper <redacted> Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
Matt Cooper [Tue, 2 Nov 2021 15:46:10 +0000 (15:46 +0000)]
odb: guard against data loss checking out a huge file
This introduces an additional guard for platforms where `unsigned long`
and `size_t` are not of the same size. If the size of an object in the
database would overflow `unsigned long`, instead we now exit with an
error.
A complete fix will have to update _many_ other functions throughout the
codebase to use `size_t` instead of `unsigned long`. It will have to be
implemented at some stage.
This commit puts in a stop-gap for the time being.
Helped-by: Johannes Schindelin <redacted> Signed-off-by: Matt Cooper <redacted> Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
Matt Cooper [Tue, 2 Nov 2021 15:46:08 +0000 (15:46 +0000)]
odb: teach read_blob_entry to use size_t
There is mixed use of size_t and unsigned long to deal with sizes in the
codebase. Recall that Windows defines unsigned long as 32 bits even on
64-bit platforms, meaning that converting size_t to unsigned long narrows
the range. This mostly doesn't cause a problem since Git rarely deals
with files larger than 2^32 bytes.
But adjunct systems such as Git LFS, which use smudge/clean filters to
keep huge files out of the repository, may have huge file contents passed
through some of the functions in entry.c and convert.c. On Windows, this
results in a truncated file being written to the workdir. I traced this to
one specific use of unsigned long in write_entry (and a similar instance
in write_pc_item_to_fd for parallel checkout). That appeared to be for
the call to read_blob_entry, which expects a pointer to unsigned long.
By altering the signature of read_blob_entry to expect a size_t,
write_entry can be switched to use size_t internally (which all of its
callers and most of its callees already used). To avoid touching dozens of
additional files, read_blob_entry uses a local unsigned long to call a
chain of functions which aren't prepared to accept size_t.
Helped-by: Johannes Schindelin <redacted> Signed-off-by: Matt Cooper <redacted> Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
Matt Cooper [Tue, 2 Nov 2021 15:46:07 +0000 (15:46 +0000)]
t1051: introduce a smudge filter test for extremely large files
The filter system allows for alterations to file contents when they're
added to the database or working tree. ("Smudge" when moving to the
working tree; "clean" when moving to the database.) This is used
natively to handle CRLF to LF conversions. It's also employed by Git-LFS
to replace large files from the working tree with small tracking files
in the repo and vice versa.
Git reads the entire smudged file into memory to convert it into a
"clean" form to be used in-core. While this is inefficient, there's a
more insidious problem on some platforms due to inconsistency between
using unsigned long and size_t for the same type of data (size of a file
in bytes). On most 64-bit platforms, unsigned long is 64 bits, and
size_t is typedef'd to unsigned long. On Windows, however, unsigned long
is only 32 bits (and therefore on 64-bit Windows, size_t is typedef'd to
unsigned long long in order to be 64 bits).
Practically speaking, this means 64-bit Windows users of Git-LFS can't
handle files larger than 2^32 bytes. Other 64-bit platforms don't suffer
this limitation.
This commit introduces a test exposing the issue; future commits make it
pass. The test simulates the way Git-LFS works by having a tiny file
checked into the repository and expanding it to a huge file on checkout.
Helped-by: Johannes Schindelin <redacted> Signed-off-by: Matt Cooper <redacted> Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
test-tool genzeros: generate large amounts of data more efficiently
In this developer's tests, producing one gigabyte worth of NULs in a
busy loop that writes out individual bytes, unbuffered, took ~27sec.
Writing chunked 256kB buffers instead only took ~0.6sec
This matters because we are about to introduce a pair of test cases that
want to be able to produce 5GB of NULs, and we cannot use `/dev/zero`
because of the HP NonStop platform's lack of support for that device.
Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
test-genzeros: allow more than 2G zeros in Windows
d5cfd142ec (tests: teach the test-tool to generate NUL bytes and
use it, 2019-02-14), add a way to generate zeroes in a portable
way without using /dev/zero (needed by HP NonStop), but uses a
long variable that is limited to 2^31 in Windows.
Use instead a (POSIX/C99) intmax_t that is at least 64bit wide
in 64-bit Windows to use in a future test.
Signed-off-by: Carlo Marcelo Arenas Belón <redacted> Signed-off-by: Johannes Schindelin <redacted> Signed-off-by: Junio C Hamano <redacted>
Phillip Wood [Tue, 2 Nov 2021 21:30:51 +0000 (21:30 +0000)]
rebase -i: fix rewording with --committer-date-is-author-date
baf8ec8d3a (rebase -r: don't write .git/MERGE_MSG when
fast-forwarding, 2021-08-20) stopped reading the author script in
run_git_commit() when rewording a commit. This is normally safe
because "git commit --amend" preserves the authorship. However if the
user passes "--committer-date-is-author-date" then we need to read the
author date from the author script when rewording. Fix this regression
by tightening the check for when it is safe to skip reading the author
script.
Reported-by: Jonas Kittner <redacted> Signed-off-by: Phillip Wood <redacted> Signed-off-by: Junio C Hamano <redacted>
Derrick Stolee [Tue, 2 Nov 2021 14:40:06 +0000 (10:40 -0400)]
dir: fix directory-matching bug
This reverts the change from ed49584 (dir: fix pattern matching on dirs,
2021-09-24), which claimed to fix a directory-matching problem without a
test case. It turns out to _create_ a bug, but it is a bit subtle.
The bug would have been revealed by the first of two tests being added to
t0008-ignores.sh. The first uses a pattern "/git/" inside the a/.gitignores
file, which matches against 'a/git/foo' but not 'a/git-foo/bar'. This test
would fail before the revert.
The second test shows what happens if the test instead uses a pattern "git/"
and this test passes both before and after the revert.
The difference in these two cases are due to how
last_matching_pattern_from_list() checks patterns both if they have the
PATTERN_FLAG_MUSTBEDIR and PATTERN_FLAG_NODIR flags. In the case of "git/",
the PATTERN_FLAG_NODIR is also provided, making the change in behavior in
match_pathname() not affect the end result of
last_matching_pattern_from_list().
Reported-by: Glen Choo <redacted> Signed-off-by: Derrick Stolee <redacted> Signed-off-by: Junio C Hamano <redacted>
René Scharfe [Sat, 30 Oct 2021 17:07:38 +0000 (19:07 +0200)]
gpg-interface: avoid buffer overrun in parse_ssh_output()
If the string "key" we found in the output of ssh-keygen happens to be
located at the very end of the line, then going four characters further
leaves us beyond the end of the string. Explicitly search for the
space after "key" to handle a missing one gracefully.
Signed-off-by: René Scharfe <redacted> Acked-by: Fabian Stelzer <redacted> Signed-off-by: Junio C Hamano <redacted>
René Scharfe [Sat, 30 Oct 2021 17:04:56 +0000 (19:04 +0200)]
gpg-interface: handle missing " with " gracefully in parse_ssh_output()
If the output of ssh-keygen starts with "Good \"git\" signature for ",
but is not followed by " with " for some reason, then parse_ssh_output()
uses -1 as the len parameter of xmemdupz(), which in turn will end the
program. Reject the signature and carry on instead in that case.
Signed-off-by: René Scharfe <redacted> Acked-by: Fabian Stelzer <redacted> Signed-off-by: Junio C Hamano <redacted>
Teach "git commit-graph" command not to allow using replace objects
at all, as we do not use the commit-graph at runtime when we see
object replacement.
Junio C Hamano [Mon, 1 Nov 2021 20:48:08 +0000 (13:48 -0700)]
Merge branch 'hm/paint-hits-in-log-grep'
"git log --grep=string --author=name" learns to highlight hits just
like "git grep string" does.
* hm/paint-hits-in-log-grep:
grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data
pretty: colorize pattern matches in commit messages
grep: refactor next_match() and match_one_pattern() for external use
leak tests: mark some fast-import tests as passing with SANITIZE=leak
Mark some tests that match "*fast-import*" as passing when git is
compiled with SANITIZE=leak. They'll now be listed as running under
the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks"
CI target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some config tests as passing with SANITIZE=leak
Mark some tests that match "*config*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some status tests as passing with SANITIZE=leak
Mark some tests that match "*status*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some clone tests as passing with SANITIZE=leak
Mark some tests that match "*clone*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some add tests as passing with SANITIZE=leak
Mark some tests that match "*add*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some diff tests as passing with SANITIZE=leak
Mark some tests that match "*diff*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some apply tests as passing with SANITIZE=leak
Mark some tests that match "*apply*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some notes tests as passing with SANITIZE=leak
Mark some tests that match "*notes*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some update-index tests as passing with SANITIZE=leak
Mark some tests that match "*update-index*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some rev-parse tests as passing with SANITIZE=leak
Mark some tests that match "*rev-parse*" as passing when git is
compiled with SANITIZE=leak. They'll now be listed as running under
the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks"
CI target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some rev-list tests as passing with SANITIZE=leak
Mark some tests that match "*rev-list*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark some misc tests as passing with SANITIZE=leak
As in 7ff24785cb7 (leak tests: mark some misc tests as passing with
SANITIZE=leak, 2021-10-12) continue marking various miscellaneous
tests as passing when git is compiled with SANITIZE=leak. They'll now
be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true"
test mode (the "linux-leaks" CI target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark most gettext tests as passing with SANITIZE=leak
Mark all but one tests that match "*gettext*" as passing when git is compiled
with SANITIZE=leak. They'll now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
In the case of "t0202-gettext-perl.sh" this isn't very meaningful as
most of the work is on the Perl side, but let's mark it anyway.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark "sort" test as passing SANITIZE=leak
Mark a test that was recently added in e031e9719d2 (test-mergesort:
add test subcommand, 2021-10-01) as passing with SANITIZE=leak. It
will now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
leak tests: mark a read-tree test as passing SANITIZE=leak
The "t1002-read-tree-m-u-2way.sh" test has passed under SANITIZE=leak
since 04988c8d182 (unpack-trees: introduce preserve_ignored to
unpack_trees_options, 2021-09-27) was combined with e5a917fcf42 (unpack-trees: don't leak memory in
verify_clean_subdirectory(), 2021-10-07), but as both were in-flight
at the time neither could mark it as passing.
It will now be listed as running under the
"GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI
target).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted> Signed-off-by: Junio C Hamano <redacted>
Eli Schwartz [Sun, 31 Oct 2021 17:15:10 +0000 (13:15 -0400)]
pretty: add abbrev option to %(describe)
The %(describe) placeholder by default, like `git describe`, uses a
seven-character abbreviated commit object name. This may not be
sufficient to fully describe all commits in a given repository,
resulting in a placeholder replacement changing its length because the
repository grew in size. This could cause the output of git-archive to
change.
Add the --abbrev option to `git describe` to the placeholder interface
in order to provide tools to the user for fine-tuning project defaults
and ensure reproducible archives.
One alternative would be to just always specify --abbrev=40 but this may
be a bit too biased...
Signed-off-by: Eli Schwartz <redacted> Signed-off-by: Junio C Hamano <redacted>
Eli Schwartz [Sun, 31 Oct 2021 17:15:09 +0000 (13:15 -0400)]
pretty: add tag option to %(describe)
The %(describe) placeholder by default, like `git describe`, only
supports annotated tags. However, some people do use lightweight tags
for releases, and would like to describe those anyway. The command line
tool has an option to support this.
Teach the placeholder to support this as well.
Signed-off-by: Eli Schwartz <redacted> Signed-off-by: Junio C Hamano <redacted>
Eli Schwartz [Sun, 31 Oct 2021 17:15:08 +0000 (13:15 -0400)]
pretty.c: rework describe options parsing for better extensibility
It contains option arguments only, not options. We would like to add
option support here too, but to do that we need to distinguish between
different types of options.
Lay out the groundwork for distinguishing between bools, strings, etc.
and move the central logic (validating values and pushing new arguments
to *args) into the successful match, because that will be fairly
conditional on what type of argument is being parsed.
Signed-off-by: Eli Schwartz <redacted> Signed-off-by: Junio C Hamano <redacted>
Daniel Santos [Wed, 11 Aug 2021 18:29:16 +0000 (19:29 +0100)]
l10n: pt_PT: cleaning duplicate translations (#2)
* cleaning duplicate incorrect translations part 2
* update translation table
* unfuzzy all entries
* typos check in git commands and git flags
* random line translations
* updating all phrases #1
Jiang Xin [Mon, 1 Nov 2021 02:14:17 +0000 (10:14 +0800)]
i18n: fix typos found during l10n for git 2.34.0
Emir and Jean-Noël reported typos in some i18n messages when preparing
l10n for git 2.34.0.
* Fix unstable spelling of config variable "gpg.ssh.defaultKeyCommand"
which was introduced in commit fd9e226776 (ssh signing: retrieve a
default key from ssh-agent, 2021-09-10).
* Add missing space between "with" and "--python" which was introduced
in commit bd0708c7eb (ref-filter: add %(raw) atom, 2021-07-26).
* Fix unmatched single quote in 'builtin/index-pack.c' which was
introduced in commit 8737dab346 (index-pack: refactor renaming in
final(), 2021-09-09)
[1] https://github.com/git-l10n/git-po/pull/567
Reported-by: Emir Sarı <redacted> Reported-by: Jean-Noël Avila <redacted> Signed-off-by: Jiang Xin <redacted> Signed-off-by: Junio C Hamano <redacted>
Jiang Xin [Sat, 30 Oct 2021 01:34:30 +0000 (09:34 +0800)]
Merge branch 'master' of github.com:git/git
* 'master' of github.com:git/git: (762 commits)
Git 2.34-rc0
wrapper: remove xunsetenv()
log: document --encoding behavior on iconv() failure
Revert "logmsg_reencode(): warn when iconv() fails"
completion: fix incorrect bash/zsh string equality check
add, rm, mv: fix bug that prevents the update of non-sparse dirs
git-bundle.txt: add missing words and punctuation
Documentation/Makefile: fix lint-docs mkdir dependency
submodule: drop unused sm_name parameter from append_fetch_remotes()
The fifteenth batch
gitweb.txt: change "folder" to "directory"
gitignore.txt: change "folder" to "directory"
git-multi-pack-index.txt: change "folder" to "directory"
git.txt: fix typo
archive: describe compression level option
config.txt: fix typo
command-list.txt: remove 'sparse-index' from main help
userdiff-cpp: back out the digit-separators in numbers
submodule--helper: fix incorrect newlines in an error message
branch (doc): -m/-c copies config and reflog
...
Junio C Hamano [Fri, 29 Oct 2021 22:43:14 +0000 (15:43 -0700)]
Merge branch 'ks/submodule-add-message-fix'
Message regression fix.
* ks/submodule-add-message-fix:
submodule: drop unused sm_name parameter from append_fetch_remotes()
submodule--helper: fix incorrect newlines in an error message
Junio C Hamano [Fri, 29 Oct 2021 22:43:13 +0000 (15:43 -0700)]
Merge branch 'ab/plug-random-leaks'
Leakfix.
* ab/plug-random-leaks:
reflog: free() ref given to us by dwim_log()
submodule--helper: fix small memory leaks
clone: fix a memory leak of the "git_dir" variable
grep: fix a "path_list" memory leak
grep: use object_array_clear() in cmd_grep()
grep: prefer "struct grep_opt" over its "void *" equivalent
Junio C Hamano [Fri, 29 Oct 2021 22:43:12 +0000 (15:43 -0700)]
Merge branch 'ab/ref-filter-leakfix'
"git for-each-ref" family of commands were leaking the ref_sorting
instances that hold sorting keys specified by the user; this has
been corrected.
* ab/ref-filter-leakfix:
branch: use ref_sorting_release()
ref-filter API user: add and use a ref_sorting_release()
tag: use a "goto cleanup" pattern, leak less memory
Junio C Hamano [Fri, 29 Oct 2021 22:43:12 +0000 (15:43 -0700)]
Merge branch 'jk/http-push-status-fix'
"git push" client talking to an HTTP server did not diagnose the
lack of the final status report from the other side correctly,
which has been corrected.
* jk/http-push-status-fix:
transport-helper: recognize "expecting report" error from send-pack
send-pack: complain about "expecting report" with --helper-status
Junio C Hamano [Fri, 29 Oct 2021 21:42:12 +0000 (14:42 -0700)]
unsetenv(3) returns int, not void
This compatilibity implementation has been returning a wrong type,
ever since 731043fd (Add compat/unsetenv.c ., 2006-01-25) added to
the system, yet nobody noticed it in the past 16 years, presumably
because no code checks failures in their unsetenv() calls. Sigh.
Jeff King [Fri, 29 Oct 2021 21:10:03 +0000 (17:10 -0400)]
log: document --encoding behavior on iconv() failure
We already note that we may produce invalid output when we skip calling
iconv() altogether. But we may also do so if iconv() fails, and we have
no good alternative. Let's document this to avoid surprising users.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Fri, 29 Oct 2021 20:48:58 +0000 (13:48 -0700)]
Revert "logmsg_reencode(): warn when iconv() fails"
This reverts commit fd680bc5 (logmsg_reencode(): warn when iconv()
fails, 2021-08-27). Throwing a warning for each and every commit
that gets reencoded, without allowing a way to squelch, would make
it unpleasant for folks who have to deal with an ancient part of the
history in an old project that used wrong encoding in the commits.
John Cai [Fri, 29 Oct 2021 19:52:43 +0000 (19:52 +0000)]
docs: add headers in MyFirstObjectWalk
In several places, headers need to be included or else the code won't
compile. Since this is the first object walk, it would be nice to
include them in the tutorial to make it easier to follow.
Signed-off-by: John Cai <redacted> Signed-off-by: Junio C Hamano <redacted>
John Cai [Fri, 29 Oct 2021 19:52:42 +0000 (19:52 +0000)]
docs: fix places that break compilation in MyFirstObjectWalk
Two errors in the example code caused compilation failures due to
a missing semicolon as well as initialization with an empty struct.
This commit fixes that to make the MyFirstObjectWalk tutorial easier to
follow.
Signed-off-by: John Cai <redacted> Signed-off-by: Junio C Hamano <redacted>
Eric Wong [Fri, 29 Oct 2021 00:15:52 +0000 (00:15 +0000)]
tests: disable fsync everywhere
The "GIT_TEST_FSYNC" environment variable now exists for
disabling fsync() even on packfiles and other "critical" data.
Running "make test -j8 NO_SVN_TESTS=1" on a noisy 8-core system
on an HDD, test runtime drops from ~4 minutes down to ~3 minutes.
Using "GIT_TEST_FSYNC=1" re-enables fsync() for comparison
purposes.
SVN interopability tests are minimally affected since SVN will
still use fsync in various places.
This will also be useful for 3rd-party tools which create
throwaway git repositories of temporary data, but remains
undocumented for end users.
Signed-off-by: Eric Wong <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Wed, 20 Oct 2021 17:28:44 +0000 (10:28 -0700)]
pull: --ff-only should make it a noop when already-up-to-date
Earlier, we made sure that "git pull --ff-only" (and "git -c
pull.ff=only pull") errors out when our current HEAD is not an
ancestor of the tip of the history we are merging, but the condition
to trigger the error was implemented incorrectly.
Imagine you forked from a remote branch, built your history on top
of it, and then attempted to pull from them again. If they have not
made any update in the meantime, our current HEAD is obviously not
their ancestor, and this new error triggers.
Without the --ff-only option, we just report that there is no need
to pull; we did the same historically with --ff-only, too.
Make sure we do not fail with the recently added check to restore
the historical behaviour.
Reported-by: Kenneth Arnold <redacted> Helped-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Thu, 28 Oct 2021 19:20:27 +0000 (15:20 -0400)]
t5310: drop lib-bundle.sh include
Commit ddfe900612 (test-lib-functions: move function to lib-bitmap.sh,
2021-02-09) meant to include lib-bitmap.sh in t5310, but also includes
lib-bundle.sh. Yet we don't use any of its functions, nor have anything
to do with bundles. This is probably just a typo/copy-paste error, as
lib-bundle.sh was added (correctly) to other scripts in the same series.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Taylor Blau [Tue, 26 Oct 2021 21:01:26 +0000 (17:01 -0400)]
pack-bitmap.c: more aggressively free in free_bitmap_index()
The function free_bitmap_index() is somewhat lax in what it frees. There
are two notable examples:
- While it does call kh_destroy_oid_map on the "bitmaps" map, which
maps commit OIDs to their corresponding bitmaps, the bitmaps
themselves are not freed. Note here that we recycle already-freed
ewah_bitmaps into a pool, but these are handled correctly by
ewah_pool_free().
- We never bother to free the extended index's "positions" map, which
we always allocate in load_bitmap().
Fix both of these.
Signed-off-by: Taylor Blau <redacted> Signed-off-by: Junio C Hamano <redacted>
Taylor Blau [Tue, 26 Oct 2021 21:01:23 +0000 (17:01 -0400)]
pack-bitmap.c: don't leak type-level bitmaps
test_bitmap_walk() is used to implement `git rev-list --test-bitmap`,
which compares the result of the on-disk bitmaps with ones generated
on-the-fly during a revision walk.
In fa95666a40 (pack-bitmap.c: harden 'test_bitmap_walk()' to check type
bitmaps, 2021-08-24), we hardened those tests to also check the four
special type-level bitmaps, but never freed those bitmaps. We should
have, since each required an allocation when we EWAH-decompressed them.
Free those, plugging that leak, and also free the base (the scratch-pad
bitmap), too.
Signed-off-by: Taylor Blau <redacted> Signed-off-by: Junio C Hamano <redacted>
Taylor Blau [Tue, 26 Oct 2021 21:01:21 +0000 (17:01 -0400)]
midx.c: write MIDX filenames to strbuf
To ask for the name of a MIDX and its corresponding .rev file, callers
invoke get_midx_filename() and get_midx_rev_filename(), respectively.
These both invoke xstrfmt(), allocating a chunk of memory which must be
freed later on.
This makes callers in pack-bitmap.c somewhat awkward. Specifically,
midx_bitmap_filename(), which is implemented like:
this leaks the second argument to xstrfmt(), which itself was allocated
with xstrfmt(). This caller could assign both the result of
get_midx_filename() and the outer xstrfmt() to a temporary variable,
remembering to free() the former before returning. But that involves a
wasteful copy.
Instead, get_midx_filename() and get_midx_rev_filename() take a strbuf
as an output parameter. This way midx_bitmap_filename() can manipulate
and pass around a temporary buffer which it detaches back to its caller.
That allows us to implement the function without copying or open-coding
get_midx_filename() in a way that doesn't leak.
Update the other callers of get_midx_filename() and
get_midx_rev_filename() accordingly.
Signed-off-by: Taylor Blau <redacted> Signed-off-by: Junio C Hamano <redacted>
The `multi-pack-index` builtin dynamically allocates an array of
command-line option for each of its separate modes by calling
add_common_options() to concatante the common options with sub-command
specific ones.
Because this operation allocates a new array, we have to be careful to
remember to free it. We already do this in the repack and write
sub-commands, but verify and expire don't. Rectify this by calling
FREE_AND_NULL as the other modes do.
Signed-off-by: Taylor Blau <redacted> Signed-off-by: Junio C Hamano <redacted>
Taylor Blau [Thu, 28 Oct 2021 20:25:48 +0000 (16:25 -0400)]
builtin/repack.c: avoid leaking child arguments
`git repack` invokes a handful of child processes: one to write the
actual pack, and optionally ones to repack promisor objects and update
the MIDX.
Most of these are freed automatically by calling `start_command()` (which
invokes it on error) and `finish_command()` which calls it
automatically.
But repack_promisor_objects() can initialize a child_process, populate
its array of arguments, and then return from the function before even
calling start_command().
Make sure that the prepared list of arguments is freed by calling
child_process_clear() ourselves to avoid leaking memory along this path.
Signed-off-by: Taylor Blau <redacted> Signed-off-by: Junio C Hamano <redacted>
git.99rst.org / git.git / log