Skip to main content

Browse the archive

swh:1:snp:bb8853bfef8fcf2b1d37fd6404912c7606c98e48
sort by:
Revision Author Date Message Commit Date
83d5e33 Taylor Blau 06 October 2022, 00:12:39 UTC Git 2.37.4 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 23:58:33 UTC
f2798aa Taylor Blau 06 October 2022, 21:48:57 UTC Sync with 2.36.3 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 23:58:16 UTC
9a167cb Taylor Blau 30 September 2022, 20:47:00 UTC t7527: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t7527 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 23:57:52 UTC
fcdaa21 Taylor Blau 30 September 2022, 21:37:57 UTC Git 2.36.3 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:45:10 UTC
58612f8 Taylor Blau 06 October 2022, 21:44:44 UTC Sync with 2.35.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:44:44 UTC
868154b Taylor Blau 30 September 2022, 21:25:26 UTC Git 2.35.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:44:02 UTC
ac8a1db Taylor Blau 06 October 2022, 21:43:37 UTC Sync with 2.34.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:43:37 UTC
be85cfc Taylor Blau 30 September 2022, 21:22:02 UTC Git 2.34.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:43:08 UTC
478a426 Taylor Blau 06 October 2022, 21:42:55 UTC Sync with 2.33.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:42:55 UTC
7800e1d Taylor Blau 30 September 2022, 21:04:26 UTC Git 2.33.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:42:27 UTC
3957f3c Taylor Blau 06 October 2022, 21:42:02 UTC Sync with 2.32.4 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:42:02 UTC
af778cd Taylor Blau 30 September 2022, 21:00:58 UTC Git 2.32.4 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:41:15 UTC
9cbd282 Taylor Blau 06 October 2022, 21:40:44 UTC Sync with 2.31.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:40:44 UTC
ecf9b4a Taylor Blau 30 September 2022, 20:56:02 UTC Git 2.31.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:39:26 UTC
1225129 Taylor Blau 06 October 2022, 21:39:15 UTC Sync with 2.30.6 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:39:15 UTC
abd4d67 Taylor Blau 30 September 2022, 20:32:10 UTC Git 2.30.6 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:38:16 UTC
d9fcaee Taylor Blau 30 September 2022, 20:47:00 UTC t5537: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t5537 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 00:19:15 UTC
541607d Taylor Blau 30 September 2022, 20:47:00 UTC t3206: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t3206 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 00:19:08 UTC
8a7bfa0 Taylor Blau 30 September 2022, 20:47:00 UTC t7814: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t7814 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:31:40 UTC
59f2f80 Taylor Blau 30 September 2022, 20:47:00 UTC t5537: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t5537 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:31:36 UTC
c193e6b Taylor Blau 30 September 2022, 20:47:00 UTC t5516: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t5516 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:31:34 UTC
e175fb5 Taylor Blau 30 September 2022, 20:47:00 UTC t3207: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t3207 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:31:31 UTC
ef374dd Taylor Blau 30 September 2022, 20:48:56 UTC t2080: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t1092 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:30:45 UTC
092d3a2 Taylor Blau 30 September 2022, 20:47:00 UTC t1092: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t1092 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:30:43 UTC
067aa8f Taylor Blau 30 September 2022, 20:48:56 UTC t2080: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t1092 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:27:18 UTC
4a7dab5 Taylor Blau 30 September 2022, 20:47:00 UTC t1092: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t1092 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:27:14 UTC
0ca6ead Kevin Backhouse 28 September 2022, 22:53:32 UTC alias.c: reject too-long cmdline strings in split_cmdline() This function improperly uses an int to represent the number of entries in the resulting argument array. This allows a malicious actor to intentionally overflow the return value, leading to arbitrary heap writes. Because the resulting argv array is typically passed to execv(), it may be possible to leverage this attack to gain remote code execution on a victim machine. This was almost certainly the case for certain configurations of git-shell until the previous commit limited the size of input it would accept. Other calls to split_cmdline() are typically limited by the size of argv the OS is willing to hand us, so are similarly protected. So this is not strictly fixing a known vulnerability, but is a hardening of the function that is worth doing to protect against possible unknown vulnerabilities. One approach to fixing this would be modifying the signature of `split_cmdline()` to look something like: int split_cmdline(char *cmdline, const char ***argv, size_t *argc); Where the return value of `split_cmdline()` is negative for errors, and zero otherwise. If non-NULL, the `*argc` pointer is modified to contain the size of the `**argv` array. But this implies an absurdly large `argv` array, which more than likely larger than the system's argument limit. So even if split_cmdline() allowed this, it would fail immediately afterwards when we called execv(). So instead of converting all of `split_cmdline()`'s callers to work with `size_t` types in this patch, instead pursue the minimal fix here to prevent ever returning an array with more than INT_MAX entries in it. Signed-off-by: Kevin Backhouse <kevinbackhouse@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
71ad7fe Jeff King 28 September 2022, 22:52:48 UTC shell: limit size of interactive commands When git-shell is run in interactive mode (which must be enabled by creating $HOME/git-shell-commands), it reads commands from stdin, one per line, and executes them. We read the commands with git_read_line_interactively(), which uses a strbuf under the hood. That means we'll accept an input of arbitrary size (limited only by how much heap we can allocate). That creates two problems: - the rest of the code is not prepared to handle large inputs. The most serious issue here is that split_cmdline() uses "int" for most of its types, which can lead to integer overflow and out-of-bounds array reads and writes. But even with that fixed, we assume that we can feed the command name to snprintf() (via xstrfmt()), which is stuck for historical reasons using "int", and causes it to fail (and even trigger a BUG() call). - since the point of git-shell is to take input from untrusted or semi-trusted clients, it's a mild denial-of-service. We'll allocate as many bytes as the client sends us (actually twice as many, since we immediately duplicate the buffer). We can fix both by just limiting the amount of per-command input we're willing to receive. We should also fix split_cmdline(), of course, which is an accident waiting to happen, but that can come on top. Most calls to split_cmdline(), including the other one in git-shell, are OK because they are reading from an OS-provided argv, which is limited in practice. This patch should eliminate the immediate vulnerabilities. I picked 4MB as an arbitrary limit. It's big enough that nobody should ever run into it in practice (since the point is to run the commands via exec, we're subject to OS limits which are typically much lower). But it's small enough that allocating it isn't that big a deal. The code is mostly just swapping out fgets() for the strbuf call, but we have to add a few niceties like flushing and trimming line endings. We could simplify things further by putting the buffer on the stack, but 4MB is probably a bit much there. Note that we'll _always_ allocate 4MB, which for normal, non-malicious requests is more than we would before this patch. But on the other hand, other git programs are happy to use 96MB for a delta cache. And since we'd never touch most of those pages, on a lazy-allocating OS like Linux they won't even get allocated to actual RAM. The ideal would be a version of strbuf_getline() that accepted a maximum value. But for a minimal vulnerability fix, let's keep things localized and simple. We can always refactor further on top. The included test fails in an obvious way with ASan or UBSan (which notice the integer overflow and out-of-bounds reads). Without them, it fails in a less obvious way: we may segfault, or we may try to xstrfmt() a long string, leading to a BUG(). Either way, it fails reliably before this patch, and passes with it. Note that we don't need an EXPENSIVE prereq on it. It does take 10-15s to fail before this patch, but with the new limit, we fail almost immediately (and the perl process generating 2GB of data exits via SIGPIPE). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
32696a4 Jeff King 28 September 2022, 22:50:36 UTC shell: add basic tests We have no tests of even basic functionality of git-shell. Let's add a couple of obvious ones. This will serve as a framework for adding tests for new things we fix, as well as making sure we don't screw anything up too badly while doing so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
a1d4f67 Taylor Blau 29 July 2022, 19:22:13 UTC transport: make `protocol.file.allow` be "user" by default An earlier patch discussed and fixed a scenario where Git could be used as a vector to exfiltrate sensitive data through a Docker container when a potential victim clones a suspicious repository with local submodules that contain symlinks. That security hole has since been plugged, but a similar one still exists. Instead of convincing a would-be victim to clone an embedded submodule via the "file" protocol, an attacker could convince an individual to clone a repository that has a submodule pointing to a valid path on the victim's filesystem. For example, if an individual (with username "foo") has their home directory ("/home/foo") stored as a Git repository, then an attacker could exfiltrate data by convincing a victim to clone a malicious repository containing a submodule pointing at "/home/foo/.git" with `--recurse-submodules`. Doing so would expose any sensitive contents in stored in "/home/foo" tracked in Git. For systems (such as Docker) that consider everything outside of the immediate top-level working directory containing a Dockerfile as inaccessible to the container (with the exception of volume mounts, and so on), this is a violation of trust by exposing unexpected contents in the working copy. To mitigate the likelihood of this kind of attack, adjust the "file://" protocol's default policy to be "user" to prevent commands that execute without user input (including recursive submodule initialization) from taking place by default. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
f4a32a5 Taylor Blau 29 July 2022, 19:21:53 UTC t/t9NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that interact with submodules a handful of times use `test_config_global`. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
0d3beb7 Taylor Blau 29 July 2022, 19:21:40 UTC t/t7NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
0f21b8f Taylor Blau 29 July 2022, 19:21:18 UTC t/t6NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
225d2d5 Taylor Blau 29 July 2022, 19:21:06 UTC t/t5NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
ac7e57f Taylor Blau 29 July 2022, 19:20:43 UTC t/t4NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
f8d510e Taylor Blau 29 July 2022, 19:20:28 UTC t/t3NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
99f4abb Taylor Blau 29 July 2022, 19:20:03 UTC t/2NNNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
8a96dbc Taylor Blau 29 July 2022, 19:16:10 UTC t/t1NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
7de0c30 Taylor Blau 29 July 2022, 19:13:58 UTC t/lib-submodule-update.sh: allow local submodules To prepare for changing the default value of `protocol.file.allow` to "user", update the `prolog()` function in lib-submodule-update to allow submodules to be cloned over the file protocol. This is used by a handful of submodule-related test scripts, which themselves will have to tweak the value of `protocol.file.allow` in certain locations. Those will be done in subsequent commits. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
6f054f9 Taylor Blau 28 July 2022, 21:35:17 UTC builtin/clone.c: disallow `--local` clones with symlinks When cloning a repository with `--local`, Git relies on either making a hardlink or copy to every file in the "objects" directory of the source repository. This is done through the callpath `cmd_clone()` -> `clone_local()` -> `copy_or_link_directory()`. The way this optimization works is by enumerating every file and directory recursively in the source repository's `$GIT_DIR/objects` directory, and then either making a copy or hardlink of each file. The only exception to this rule is when copying the "alternates" file, in which case paths are rewritten to be absolute before writing a new "alternates" file in the destination repo. One quirk of this implementation is that it dereferences symlinks when cloning. This behavior was most recently modified in 36596fd2df (clone: better handle symlinked files at .git/objects/, 2019-07-10), which attempted to support `--local` clones of repositories with symlinks in their objects directory in a platform-independent way. Unfortunately, this behavior of dereferencing symlinks (that is, creating a hardlink or copy of the source's link target in the destination repository) can be used as a component in attacking a victim by inadvertently exposing the contents of file stored outside of the repository. Take, for example, a repository that stores a Dockerfile and is used to build Docker images. When building an image, Docker copies the directory contents into the VM, and then instructs the VM to execute the Dockerfile at the root of the copied directory. This protects against directory traversal attacks by copying symbolic links as-is without dereferencing them. That is, if a user has a symlink pointing at their private key material (where the symlink is present in the same directory as the Dockerfile, but the key itself is present outside of that directory), the key is unreadable to a Docker image, since the link will appear broken from the container's point of view. This behavior enables an attack whereby a victim is convinced to clone a repository containing an embedded submodule (with a URL like "file:///proc/self/cwd/path/to/submodule") which has a symlink pointing at a path containing sensitive information on the victim's machine. If a user is tricked into doing this, the contents at the destination of those symbolic links are exposed to the Docker image at runtime. One approach to preventing this behavior is to recreate symlinks in the destination repository. But this is problematic, since symlinking the objects directory are not well-supported. (One potential problem is that when sharing, e.g. a "pack" directory via symlinks, different writers performing garbage collection may consider different sets of objects to be reachable, enabling a situation whereby garbage collecting one repository may remove reachable objects in another repository). Instead, prohibit the local clone optimization when any symlinks are present in the `$GIT_DIR/objects` directory of the source repository. Users may clone the repository again by prepending the "file://" scheme to their clone URL, or by adding the `--no-local` option to their `git clone` invocation. The directory iterator used by `copy_or_link_directory()` must no longer dereference symlinks (i.e., it *must* call `lstat()` instead of `stat()` in order to discover whether or not there are symlinks present). This has no bearing on the overall behavior, since we will immediately `die()` on encounter a symlink. Note that t5604.33 suggests that we do support local clones with symbolic links in the source repository's objects directory, but this was likely unintentional, or at least did not take into consideration the problem with sharing parts of the objects directory with symbolic links at the time. Update this test to reflect which options are and aren't supported. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
a0feb86 Junio C Hamano 13 September 2022, 19:18:30 UTC Merge a handful of topics from the 'master' front As the 'master' front will soon tag a preview and then release candidates for 2.38, it is unknown if we are going to issue another maintenance release on the 2.37.x track, but as we have accumulated enough material there, let's prepare a draft for it. Even if we end up not tagging 2.37.4, it would help motivated distro packagers to maintain their slightly older and "more stable" versions. Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 September 2022, 19:22:59 UTC
2c75b32 Junio C Hamano 13 September 2022, 19:21:11 UTC Merge branch 'en/merge-unstash-only-on-clean-merge' into maint The auto-stashed local changes created by "git merge --autostash" was mixed into a conflicted state left in the working tree, which has been corrected. * en/merge-unstash-only-on-clean-merge: merge: only apply autostash when appropriate 13 September 2022, 19:21:11 UTC
4f06dfd Junio C Hamano 13 September 2022, 19:21:10 UTC Merge branch 'ds/github-actions-use-newer-ubuntu' into maint Update the version of Ubuntu used for GitHub Actions CI from 18.04 to 22.04. * ds/github-actions-use-newer-ubuntu: ci: update 'static-analysis' to Ubuntu 22.04 13 September 2022, 19:21:10 UTC
37317ab Junio C Hamano 13 September 2022, 19:21:10 UTC Merge branch 'ad/preload-plug-memleak' into maint The preload-index codepath made copies of pathspec to give to multiple threads, which were left leaked. * ad/preload-plug-memleak: preload-index: fix memleak 13 September 2022, 19:21:10 UTC
c61614e Junio C Hamano 13 September 2022, 19:21:09 UTC Merge branch 'sg/xcalloc-cocci-fix' into maint xcalloc(), imitating calloc(), takes "number of elements of the array", and "size of a single element", in this order. A call that does not follow this ordering has been corrected. * sg/xcalloc-cocci-fix: promisor-remote: fix xcalloc() argument order 13 September 2022, 19:21:09 UTC
aa31cb8 Junio C Hamano 13 September 2022, 19:21:08 UTC Merge branch 'jk/pipe-command-nonblock' into maint Fix deadlocks between main Git process and subprocess spawned via the pipe_command() API, that can kill "git add -p" that was reimplemented in C recently. * jk/pipe-command-nonblock: pipe_command(): mark stdin descriptor as non-blocking pipe_command(): handle ENOSPC when writing to a pipe pipe_command(): avoid xwrite() for writing to pipe git-compat-util: make MAX_IO_SIZE define globally available nonblock: support Windows compat: add function to enable nonblocking pipes 13 September 2022, 19:21:08 UTC
72869e7 Junio C Hamano 13 September 2022, 19:21:07 UTC Merge branch 'jk/is-promisor-object-keep-tree-in-use' into maint An earlier optimization discarded a tree-object buffer that is still in use, which has been corrected. * jk/is-promisor-object-keep-tree-in-use: is_promisor_object(): fix use-after-free of tree buffer 13 September 2022, 19:21:07 UTC
ac8035a Junio C Hamano 30 August 2022, 17:22:10 UTC Git 2.37.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 August 2022, 17:22:10 UTC
0f5bd02 Junio C Hamano 25 August 2022, 21:57:38 UTC A handful more topics from the 'master' front for 2.37.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 August 2022, 18:13:13 UTC
842c912 Junio C Hamano 26 August 2022, 18:13:13 UTC Merge branch 'po/doc-add-renormalize' into maint Documentation for "git add --renormalize" has been improved. source: <20220810144450.470-2-philipoakley@iee.email> * po/doc-add-renormalize: doc add: renormalize is not idempotent for CRCRLF 26 August 2022, 18:13:13 UTC
7be9f3f Junio C Hamano 26 August 2022, 18:13:12 UTC Merge branch 'vd/sparse-reset-checkout-fixes' into maint Fixes to sparse index compatibility work for "reset" and "checkout" commands. source: <pull.1312.v3.git.1659985672.gitgitgadget@gmail.com> * vd/sparse-reset-checkout-fixes: unpack-trees: unpack new trees as sparse directories cache.h: create 'index_name_pos_sparse()' oneway_diff: handle removed sparse directories checkout: fix nested sparse directory diff in sparse index 26 August 2022, 18:13:13 UTC
e5cb51d Junio C Hamano 26 August 2022, 18:13:12 UTC Merge branch 'jk/fsck-tree-mode-bits-fix' into maint "git fsck" reads mode from tree objects but canonicalizes the mode before passing it to the logic to check object sanity, which has hid broken tree objects from the checking logic. This has been corrected, but to help exiting projects with broken tree objects that they cannot fix retroactively, the severity of anomalies this code detects has been demoted to "info" for now. source: <YvQcNpizy9uOZiAz@coredump.intra.peff.net> * jk/fsck-tree-mode-bits-fix: fsck: downgrade tree badFilemode to "info" fsck: actually detect bad file modes in trees tree-walk: add a mechanism for getting non-canonicalized modes 26 August 2022, 18:13:12 UTC
222f953 Junio C Hamano 26 August 2022, 18:13:12 UTC Merge branch 'fc/vimdiff-layout-vimdiff3-fix' into maint "vimdiff3" regression fix. source: <20220810154618.307275-1-felipe.contreras@gmail.com> * fc/vimdiff-layout-vimdiff3-fix: mergetools: vimdiff: simplify tabfirst mergetools: vimdiff: fix single window layouts mergetools: vimdiff: rework tab logic mergetools: vimdiff: fix for diffopt mergetools: vimdiff: silence annoying messages mergetools: vimdiff: make vimdiff3 actually work mergetools: vimdiff: fix comment 26 August 2022, 18:13:12 UTC
10f9eab Junio C Hamano 26 August 2022, 18:13:12 UTC Merge branch 'js/safe-directory-plus' into maint Platform-specific code that determines if a directory is OK to use as a repository has been taught to report more details, especially on Windows. source: <pull.1286.v2.git.1659965270.gitgitgadget@gmail.com> * js/safe-directory-plus: mingw: handle a file owned by the Administrators group correctly mingw: be more informative when ownership check fails on FAT32 mingw: provide details about unsafe directories' ownership setup: prepare for more detailed "dubious ownership" messages setup: fix some formatting 26 August 2022, 18:13:12 UTC
6283c1e Junio C Hamano 26 August 2022, 18:13:12 UTC Merge branch 'pw/use-glibc-tunable-for-malloc-optim' into maint Avoid repeatedly running getconf to ask libc version in the test suite, and instead just as it once per script. source: <pull.1311.git.1659620305757.gitgitgadget@gmail.com> * pw/use-glibc-tunable-for-malloc-optim: tests: cache glibc version check 26 August 2022, 18:13:12 UTC
5825304 Junio C Hamano 26 August 2022, 18:13:12 UTC Merge branch 'ab/hooks-regression-fix' into maint A follow-up fix to a fix for a regression in 2.36. source: <patch-1.1-2450e3e65cf-20220805T141402Z-avarab@gmail.com> * ab/hooks-regression-fix: hook API: don't segfault on strbuf_addf() to NULL "out" 26 August 2022, 18:13:12 UTC
ed051d4 Junio C Hamano 26 August 2022, 18:13:11 UTC Merge branch 'gc/git-reflog-doc-markup' into maint Doc mark-up fix. source: <pull.1304.git.git.1659387885711.gitgitgadget@gmail.com> * gc/git-reflog-doc-markup: Documentation/git-reflog: remove unneeded \ from \{ 26 August 2022, 18:13:11 UTC
c2d62d0 Junio C Hamano 26 August 2022, 18:13:11 UTC Merge branch 'js/ort-clean-up-after-failed-merge' into maint Plug memory leaks in the failure code path in the "merge-ort" merge strategy backend. source: <pull.1307.v2.git.1659114727.gitgitgadget@gmail.com> * js/ort-clean-up-after-failed-merge: merge-ort: do leave trace2 region even if checkout fails merge-ort: clean up after failed merge 26 August 2022, 18:13:11 UTC
4b2d41b Junio C Hamano 26 August 2022, 18:13:10 UTC Merge branch 'jk/struct-zero-init-with-older-gcc' into maint Older gcc with -Wall complains about the universal zero initializer "struct s = { 0 };" idiom, which makes developers' lives inconvenient (as -Werror is enabled by DEVELOPER=YesPlease). The build procedure has been tweaked to help these compilers. source: <YuQ60ZUPBHAVETD7@coredump.intra.peff.net> * jk/struct-zero-init-with-older-gcc: config.mak.dev: squelch -Wno-missing-braces for older gcc 26 August 2022, 18:13:11 UTC
69c99b8 Junio C Hamano 26 August 2022, 18:13:10 UTC Merge branch 'js/lstat-mingw-enotdir-fix' into maint Fix to lstat() emulation on Windows. source: <pull.1291.v3.git.1659089152877.gitgitgadget@gmail.com> * js/lstat-mingw-enotdir-fix: lstat(mingw): correctly detect ENOTDIR scenarios 26 August 2022, 18:13:10 UTC
9166bca Junio C Hamano 26 August 2022, 18:13:10 UTC Merge branch 'js/mingw-with-python' into maint Conditionally allow building Python interpreter on Windows source: <pull.1306.v2.git.1659109272.gitgitgadget@gmail.com> * js/mingw-with-python: mingw: remove unneeded `NO_CURL` directive mingw: remove unneeded `NO_GETTEXT` directive windows: include the Python bits when building Git for Windows 26 August 2022, 18:13:10 UTC
2794e81 Junio C Hamano 26 August 2022, 18:13:10 UTC Merge branch 'ca/unignore-local-installation-on-windows' into maint Fix build procedure for Windows that uses CMake so that it can pick up the shell interpreter from local installation location. source: <pull.1304.git.1658912756815.gitgitgadget@gmail.com> * ca/unignore-local-installation-on-windows: cmake: support local installations of git 26 August 2022, 18:13:10 UTC
ef46584 Derrick Stolee 23 August 2022, 17:28:11 UTC ci: update 'static-analysis' to Ubuntu 22.04 GitHub Actions scheduled a brownout of Ubuntu 18.04, which canceled all runs of the 'static-analysis' job in our CI runs. Update to 22.04 to avoid this as the brownout later turns into a complete deprecation. The use of 18.04 was set in d051ed77ee6 (.github/workflows/main.yml: run static-analysis on bionic, 2021-02-08) due to the lack of Coccinelle being available on 20.04 (which continues today). Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 August 2022, 20:02:12 UTC
d3a9295 Elijah Newren 23 August 2022, 02:42:19 UTC merge: only apply autostash when appropriate If a merge failed and we are leaving conflicts in the working directory for the user to resolve, we should not attempt to apply any autostash. Further, if we fail to apply the autostash (because either the merge failed, or the user requested --no-commit), then we should instruct the user how to apply it later. Add a testcase verifying we have corrected this behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 August 2022, 16:08:32 UTC
c4bbd9b SZEDER Gábor 23 August 2022, 09:57:33 UTC promisor-remote: fix xcalloc() argument order Pass the number of elements first and their size second, as expected by xcalloc(). Patch generated with: make SPATCH_FLAGS=--recursive-includes contrib/coccinelle/xcalloc.cocci.patch Our default SPATCH_FLAGS ('--all-includes') doesn't catch this transformation by default, unless used in combination with a large-ish SPATCH_BATCH_SIZE which happens to put 'promisor-remote.c' with a file that includes 'repository.h' directly in the same batch. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 August 2022, 15:50:39 UTC
2357890 Anthony Delannoy 22 August 2022, 21:15:07 UTC preload-index: fix memleak Fix a memory leak occuring in case of pathspec copy in preload_index. Direct leak of 8 byte(s) in 8 object(s) allocated from: #0 0x7f0a353ead47 in __interceptor_malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libasan.so.6+0xb5d47) #1 0x55750995e840 in do_xmalloc /home/anthony/src/c/git/wrapper.c:51 #2 0x55750995e840 in xmalloc /home/anthony/src/c/git/wrapper.c:72 #3 0x55750970f824 in copy_pathspec /home/anthony/src/c/git/pathspec.c:684 #4 0x557509717278 in preload_index /home/anthony/src/c/git/preload-index.c:135 #5 0x55750975f21e in refresh_index /home/anthony/src/c/git/read-cache.c:1633 #6 0x55750915b926 in cmd_status builtin/commit.c:1547 #7 0x5575090e1680 in run_builtin /home/anthony/src/c/git/git.c:466 #8 0x5575090e1680 in handle_builtin /home/anthony/src/c/git/git.c:720 #9 0x5575090e284a in run_argv /home/anthony/src/c/git/git.c:787 #10 0x5575090e284a in cmd_main /home/anthony/src/c/git/git.c:920 #11 0x5575090dbf82 in main /home/anthony/src/c/git/common-main.c:56 #12 0x7f0a348230ab (/lib64/libc.so.6+0x290ab) Signed-off-by: Anthony Delannoy <anthony.2lannoy@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 August 2022, 22:08:30 UTC
716c1f6 Jeff King 17 August 2022, 06:10:22 UTC pipe_command(): mark stdin descriptor as non-blocking Our pipe_command() helper lets you both write to and read from a child process on its stdin/stdout. It's supposed to work without deadlocks because we use poll() to check when descriptors are ready for reading or writing. But there's a bug: if both the data to be written and the data to be read back exceed the pipe buffer, we'll deadlock. The issue is that the code assumes that if you have, say, a 2MB buffer to write and poll() tells you that the pipe descriptor is ready for writing, that calling: write(cmd->in, buf, 2*1024*1024); will do a partial write, filling the pipe buffer and then returning what it did write. And that is what it would do on a socket, but not for a pipe. When writing to a pipe, at least on Linux, it will block waiting for the child process to read() more. And now we have a potential deadlock, because the child may be writing back to us, waiting for us to read() ourselves. An easy way to trigger this is: git -c add.interactive.useBuiltin=true \ -c interactive.diffFilter=cat \ checkout -p HEAD~200 The diff against HEAD~200 will be big, and the filter wants to write all of it back to us (obviously this is a dummy filter, but in the real world something like diff-highlight would similarly stream back a big output). If you set add.interactive.useBuiltin to false, the problem goes away, because now we're not using pipe_command() anymore (instead, that part happens in perl). But this isn't a bug in the interactive code at all. It's the underlying pipe_command() code which is broken, and has been all along. We presumably didn't notice because most calls only do input _or_ output, not both. And the few that do both, like gpg calls, may have large inputs or outputs, but never both at the same time (e.g., consider signing, which has a large payload but a small signature comes back). The obvious fix is to put the descriptor into non-blocking mode, and indeed, that makes the problem go away. Callers shouldn't need to care, because they never see the descriptor (they hand us a buffer to feed into it). The included test fails reliably on Linux without this patch. Curiously, it doesn't fail in our Windows CI environment, but has been reported to do so for individual developers. It should pass in any environment after this patch (courtesy of the compat/ layers added in the last few commits). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 August 2022, 16:21:41 UTC
c6d3cce Jeff King 17 August 2022, 06:09:42 UTC pipe_command(): handle ENOSPC when writing to a pipe When write() to a non-blocking pipe fails because the buffer is full, POSIX says we should see EAGAIN. But our mingw_write() compat layer on Windows actually returns ENOSPC for this case. This is probably something we want to correct, but given that we don't plan to use non-blocking descriptors in a lot of places, we can work around it by just catching ENOSPC alongside EAGAIN. If we ever do fix mingw_write(), then this patch can be reverted. We don't actually use a non-blocking pipe yet, so this is still just preparation. Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 August 2022, 16:21:41 UTC
14eab81 Jeff King 17 August 2022, 06:08:06 UTC pipe_command(): avoid xwrite() for writing to pipe If xwrite() sees an EAGAIN response, it will loop forever until the write succeeds (or encounters a real error). This is due to ef1cf0167a (xwrite: poll on non-blocking FDs, 2016-06-26), with the idea that we won't be surprised by a descriptor unexpectedly set as non-blocking. But that will make things awkward when we do want a non-blocking descriptor, and a future patch will switch pipe_command() to using one. In that case, looping on EAGAIN is bad, because the process on the other end of the pipe may be waiting on us before doing another read() on the pipe, which would mean we deadlock. In practice we're not supposed to ever see EAGAIN here, since poll() will have just told us the descriptor is ready for writing. But our Windows emulation of poll() will always return "ready" for writing to a pipe descriptor! This is due to 94f4d01932 (mingw: workaround for hangs when sending STDIN, 2020-02-17). Our best bet in that case is to keep handling other descriptors, as any read() we do may allow the child command to make forward progress (i.e., its write() finishes, and then it read()s from its stdin, freeing up space in the pipe buffer). This means we might busy-loop between poll() and write() on Windows if the child command is slow to read our input, but it's much better than the alternative of deadlocking. In practice, this busy-looping should be rare: - for small inputs, we'll just write the whole thing in a single write() anyway, non-blocking or not - for larger inputs where the child reads input and then processes it before writing (e.g., gpg verifying a signature), we may make a few extra write() calls that get EAGAIN during the initial write, but once it has taken in the whole input, we'll correctly block waiting to read back the data. - for larger inputs where the child process is streaming output back (like a diff filter), we'll likewise see some extra EAGAINs, but most of them will be followed immediately by a read(), which will let the child command make forward progress. Of course it won't happen at all for now, since we don't yet use a non-blocking pipe. This is just preparation for when we do. Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 August 2022, 16:21:40 UTC
ec4f39b Jeff King 17 August 2022, 06:06:58 UTC git-compat-util: make MAX_IO_SIZE define globally available We define MAX_IO_SIZE within wrapper.c, but it's useful for any code that wants to do a raw write() for whatever reason (say, because they want different EAGAIN handling). Let's make it available everywhere. The alternative would be adding xwrite_foo() variants to give callers more options. But there's really no reason MAX_IO_SIZE needs to be abstracted away, so this give callers the most flexibility. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 August 2022, 16:21:40 UTC
24b56ae René Scharfe 17 August 2022, 06:05:25 UTC nonblock: support Windows Implement enable_pipe_nonblock() using the Windows API. This works only for pipes, but that is sufficient for this limited interface. Despite the API calls used, it handles both "named" and anonymous pipes from our pipe() emulation. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 August 2022, 16:21:40 UTC
10f7433 Jeff King 17 August 2022, 06:04:55 UTC compat: add function to enable nonblocking pipes We'd like to be able to make some of our pipes nonblocking so that poll() can be used effectively, but O_NONBLOCK isn't portable. Let's introduce a compat wrapper so this can be abstracted for each platform. The interface is as narrow as possible to let platforms do what's natural there (rather than having to implement fcntl() and a fake O_NONBLOCK for example, or having to handle other types of descriptors). The next commit will add Windows support, at which point we should be covering all platforms in practice. But if we do find some other platform without O_NONBLOCK, we'll return ENOSYS. Arguably we could just trigger a build-time #error in this case, which would catch the problem earlier. But since we're not planning to use this compat wrapper in many code paths, a seldom-seen runtime error may be friendlier for such a platform than blocking compilation completely. Our test suite would still notice it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 August 2022, 16:21:40 UTC
1490d7d Jeff King 14 August 2022, 06:29:15 UTC is_promisor_object(): fix use-after-free of tree buffer Since commit fcc07e980b (is_promisor_object(): free tree buffer after parsing, 2021-04-13), we'll always free the buffers attached to a "struct tree" after searching them for promisor links. But there's an important case where we don't want to do so: if somebody else is already using the tree! This can happen during a "rev-list --missing=allow-promisor" traversal in a partial clone that is missing one or more trees or blobs. The backtrace for the free looks like this: #1 free_tree_buffer tree.c:147 #2 add_promisor_object packfile.c:2250 #3 for_each_object_in_pack packfile.c:2190 #4 for_each_packed_object packfile.c:2215 #5 is_promisor_object packfile.c:2272 #6 finish_object__ma builtin/rev-list.c:245 #7 finish_object builtin/rev-list.c:261 #8 show_object builtin/rev-list.c:274 #9 process_blob list-objects.c:63 #10 process_tree_contents list-objects.c:145 #11 process_tree list-objects.c:201 #12 traverse_trees_and_blobs list-objects.c:344 [...] We're in the middle of walking through the entries of a tree object via process_tree_contents(). We see a blob (or it could even be another tree entry) that we don't have, so we call is_promisor_object() to check it. That function loops over all of the objects in the promisor packfile, including the tree we're currently walking. When we're done with it there, we free the tree buffer. But as we return to the walk in process_tree_contents(), it's still holding on to a pointer to that buffer, via its tree_desc iterator, and it accesses the freed memory. Even a trivial use of "--missing=allow-promisor" triggers this problem, as the included test demonstrates (it's just a vanilla --blob:none clone). We can detect this case by only freeing the tree buffer if it was allocated on our behalf. This is a little tricky since that happens inside parse_object(), and it doesn't tell us whether the object was already parsed, or whether it allocated the buffer itself. But by checking for an already-parsed tree beforehand, we can distinguish the two cases. That feels a little hacky, and does incur an extra lookup in the object-hash table. But that cost is fairly minimal compared to actually loading objects (and since we're iterating the whole pack here, we're likely to be loading most objects, rather than reusing cached results). It may also be a good direction for this function in general, as there are other possible optimizations that rely on doing some analysis before parsing: - we could detect blobs and avoid reading their contents; they can't link to other objects, but parse_object() doesn't know that we don't care about checking their hashes. - we could avoid allocating object structs entirely for most objects (since we really only need them in the oidset), which would save some memory. - promisor commits could use the commit-graph rather than loading the object from disk This commit doesn't do any of those optimizations, but I think it argues that this direction is reasonable, rather than relying on parse_object() and trying to teach it to give us more information about whether it parsed. The included test fails reliably under SANITIZE=address just when running "rev-list --missing=allow-promisor". Checking the output isn't strictly necessary to detect the bug, but it seems like a reasonable addition given the general lack of coverage for "allow-promisor" in the test suite. Reported-by: Andrew Olsen <andrew.olsen@koordinates.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 August 2022, 01:03:36 UTC
ad60ddd Junio C Hamano 11 August 2022, 04:52:03 UTC Git 2.37.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 August 2022, 04:52:36 UTC
b0fd38a Junio C Hamano 11 August 2022, 04:52:36 UTC Merge branch 'jc/string-list-cleanup' into maint Code clean-up. source: <xmqq7d471dns.fsf@gitster.g> * jc/string-list-cleanup: builtin/remote.c: use the right kind of STRING_LIST_INIT 11 August 2022, 04:52:36 UTC
3f4fa1f Junio C Hamano 11 August 2022, 04:52:35 UTC Merge branch 'mt/pkt-line-comment-tweak' into maint In-code comment clarification. source: <6a14443c101fa132498297af6d7a483520688d75.1658488203.git.matheus.bernardino@usp.br> * mt/pkt-line-comment-tweak: pkt-line.h: move comment closer to the associated code 11 August 2022, 04:52:35 UTC
5856cb9 Junio C Hamano 11 August 2022, 04:52:35 UTC Merge branch 'ma/t4200-update' into maint Test fix. source: <20220718154322.2177166-1-martin.agren@gmail.com> * ma/t4200-update: t4200: drop irrelevant code 11 August 2022, 04:52:35 UTC
042159a Junio C Hamano 11 August 2022, 04:52:34 UTC Merge branch 'tb/commit-graph-genv2-upgrade-fix' into maint There was a bug in the codepath to upgrade generation information in commit-graph from v1 to v2 format, which has been corrected. source: <cover.1657667404.git.me@ttaylorr.com> * tb/commit-graph-genv2-upgrade-fix: commit-graph: fix corrupt upgrade from generation v1 to v2 commit-graph: introduce `repo_find_commit_pos_in_graph()` t5318: demonstrate commit-graph generation v2 corruption 11 August 2022, 04:52:35 UTC
4f049a1 Junio C Hamano 11 August 2022, 04:52:34 UTC Merge branch 'tk/untracked-cache-with-uall' into maint Fix for a bug that makes write-tree to fail to write out a non-existent index as a tree, introduced in 2.37. source: <20220722212232.833188-1-martin.agren@gmail.com> * tk/untracked-cache-with-uall: read-cache: make `do_read_index()` always set up `istate->repo` 11 August 2022, 04:52:34 UTC
340a612 Junio C Hamano 11 August 2022, 04:52:33 UTC Merge branch 'mt/checkout-count-fix' into maint "git checkout" miscounted the paths it updated, which has been corrected. source: <cover.1657799213.git.matheus.bernardino@usp.br> * mt/checkout-count-fix: checkout: fix two bugs on the final count of updated entries checkout: show bug about failed entries being included in final report checkout: document bug where delayed checkout counts entries twice 11 August 2022, 04:52:34 UTC
acd3bce Junio C Hamano 11 August 2022, 04:52:33 UTC Merge branch 'cl/rerere-train-with-no-sign' into maint "rerere-train" script (in contrib/) used to honor commit.gpgSign while recreating the throw-away merges. source: <PH7PR14MB5594A27B9295E95ACA4D6A69CE8F9@PH7PR14MB5594.namprd14.prod.outlook.com> * cl/rerere-train-with-no-sign: contrib/rerere-train: avoid useless gpg sign in training 11 August 2022, 04:52:33 UTC
b1b489f Junio C Hamano 11 August 2022, 04:52:33 UTC Merge branch 'kk/p4-client-name-encoding-fix' into maint "git p4" did not handle non-ASCII client name well, which has been corrected. source: <pull.1285.v3.git.git.1658394440.gitgitgadget@gmail.com> * kk/p4-client-name-encoding-fix: git-p4: refactoring of p4CmdList() git-p4: fix bug with encoding of p4 client name 11 August 2022, 04:52:33 UTC
4fc4066 Junio C Hamano 11 August 2022, 04:52:32 UTC Merge branch 'mb/p4-utf16-crlf' into maint "git p4" working on UTF-16 files on Windows did not implement CRLF-to-LF conversion correctly, which has been corrected. source: <pull.1294.v2.git.git.1658341065221.gitgitgadget@gmail.com> * mb/p4-utf16-crlf: git-p4: fix CR LF handling for utf16 files 11 August 2022, 04:52:32 UTC
312d5b7 Junio C Hamano 11 August 2022, 04:52:32 UTC Merge branch 'hx/lookup-commit-in-graph-fix' into maint A corner case bug where lazily fetching objects from a promisor remote resulted in infinite recursion has been corrected. source: <cover.1656593279.git.hanxin.hx@bytedance.com> * hx/lookup-commit-in-graph-fix: t5330: remove run_with_limited_processses() commit-graph.c: no lazy fetch in lookup_commit_in_graph() 11 August 2022, 04:52:32 UTC
a6aeb2f Junio C Hamano 11 August 2022, 04:52:32 UTC Merge branch 'jc/resolve-undo' into maint The resolve-undo information in the index was not protected against GC, which has been corrected. source: <xmqq35f7kzad.fsf@gitster.g> * jc/resolve-undo: fsck: do not dereference NULL while checking resolve-undo data revision: mark blobs needed for resolve-undo as reachable 11 August 2022, 04:52:32 UTC
4dd3b04 Jeff King 10 August 2022, 21:04:07 UTC fsck: downgrade tree badFilemode to "info" The previous commit un-broke the "badFileMode" check; before then it was literally testing nothing. And as far as I can tell, it has been so since the very initial version of fsck. The current severity of "badFileMode" is just "warning". But in the --strict mode used by transfer.fsckObjects, that is elevated to an error. This will potentially cause hassle for users, because historical objects with bad modes will suddenly start causing pushes to many server operators to be rejected. At the same time, these bogus modes aren't actually a big risk. Because we canonicalize them everywhere besides fsck, they can't cause too much mischief in the real world. The worst thing you can do is end up with two almost-identical trees that have different hashes but are interpreted the same. That will generally cause things to be inefficient rather than wrong, and is a bug somebody working on a Git implementation would want to fix, but probably not worth inconveniencing users by refusing to push or fetch. So let's downgrade this to "info" by default, which is our setting for "mention this when fscking, but don't ever reject, even under strict mode". If somebody really wants to be paranoid, they can still adjust the level using config. Suggested-by: Xavier Morel <xavier.morel@masklinn.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 21:26:29 UTC
53602a9 Jeff King 10 August 2022, 21:02:45 UTC fsck: actually detect bad file modes in trees We use the normal tree_desc code to iterate over trees in fsck, meaning we only see the canonicalized modes it returns. And hence we'd never see anything unexpected, since it will coerce literally any garbage into one of our normal and accepted modes. We can use the new RAW_MODES flag to see the real modes, and then use the existing code to actually analyze them. The existing code is written as allow-known-good, so there's not much point in testing a variety of breakages. The one tested here should be S_IFREG but with nonsense permissions. Do note that the error-reporting here isn't great. We don't mention the specific bad mode, but just that the tree has one or more broken modes. But when you go to look at it with "git ls-tree", we'll report the canonicalized mode! This isn't ideal, but given that this should come up rarely, and that any number of other tree corruptions might force you into looking at the binary bytes via "cat-file", it's not the end of the world. And it's something we can improve on top later if we choose. Reported-by: Xavier Morel <xavier.morel@masklinn.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 21:26:27 UTC
ec18b10 Jeff King 10 August 2022, 21:01:17 UTC tree-walk: add a mechanism for getting non-canonicalized modes When using init_tree_desc() and tree_entry() to iterate over a tree, we always canonicalize the modes coming out of the tree. This is a good thing to prevent bugs or oddities in normal code paths, but it's counter-productive for tools like fsck that want to see the exact contents. We can address this by adding an option to avoid the extra canonicalization. A few notes on the implementation: - I've attached the new option to the tree_desc struct itself. The actual code change is in decode_tree_entry(), which is in turn called by the public update_tree_entry(), tree_entry(), and init_tree_desc() functions, plus their "gently" counterparts. By letting it ride along in the struct, we can avoid changing the signature of those functions, which are called many times. Plus it's conceptually simpler: you really want a particular iteration of a tree to be "raw" or not, rather than individual calls. - We still have to set the new option somewhere. The struct is initialized by init_tree_desc(). I added the new flags field only to the "gently" version. That avoids disturbing the much more numerous non-gentle callers, and it makes sense that anybody being careful about looking at raw modes would also be careful about bogus trees (i.e., the caller will be something like fsck in the first place). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 21:26:25 UTC
34133d9 Felipe Contreras 10 August 2022, 15:46:18 UTC mergetools: vimdiff: simplify tabfirst If we wrap the tabdo command there's no need for a separate command call. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 19:39:39 UTC
b6014ee Felipe Contreras 10 August 2022, 15:46:17 UTC mergetools: vimdiff: fix single window layouts Layouts with a single window other than "MERGED" do not work (e.g. "LOCAL" or "MERGED+LOCAL"). This is because as the documentation of bufdo says: The last buffer (or where an error occurred) becomes the current buffer. And we do always do bufdo the end. Additionally, we do it only once, when it should be per tab. Fix this by doing it once per tab right after it's created and before any buffer is switched. Cc: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 19:39:35 UTC
ffcc33f Felipe Contreras 10 August 2022, 15:46:16 UTC mergetools: vimdiff: rework tab logic If we treat tabs especially, the logic becomes much simpler. Cc: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 19:39:32 UTC
60184ab Felipe Contreras 10 August 2022, 15:46:15 UTC mergetools: vimdiff: fix for diffopt When diffopt has hiddenoff set and there's only one window (as is the case in the single window mode) the diff mode is turned off. We don't want that, so turn that option off. Cc: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 19:39:28 UTC
66dd83a Felipe Contreras 10 August 2022, 15:46:14 UTC mergetools: vimdiff: silence annoying messages When using the single window mode we are greeted with the following warning: "./content_LOCAL_8975" 6L, 28B "./content_BASE_8975" 6 lines, 29 bytes "./content_REMOTE_8975" 6 lines, 29 bytes "content" 16 lines, 115 bytes Press ENTER or type command to continue every time. Silence that. Suggested-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 19:39:24 UTC
79db50d Felipe Contreras 10 August 2022, 15:46:13 UTC mergetools: vimdiff: make vimdiff3 actually work When vimdiff3 was added in 7c147b77d3 (mergetools: add vimdiff3 mode, 2014-04-20), the description made clear the intention: It's similar to the default, except that the other windows are hidden. This ensures that removed/added colors are still visible on the main merge window, but the other windows not visible. However, in 0041797449 (vimdiff: new implementation with layout support, 2022-03-30) this was broken by generating a command that never creates windows, and therefore vim never shows the diff. The layout support implementation broke the whole purpose of vimdiff3, and simply shows MERGED, which is no different from simply opening the file with vim. In order to show the diff, the windows need to be created first, and then when they are hidden the diff remains (if hidenoff isn't set), but by setting the `hidden` option the initial buffers are marked as hidden thus making the feature work. Suggested-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 19:39:17 UTC
d619183 Felipe Contreras 10 August 2022, 15:46:12 UTC mergetools: vimdiff: fix comment The name of the variable is wrong, and it can be set to anything, like 1. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 19:39:07 UTC
efae7ce Philip Oakley 10 August 2022, 14:44:50 UTC doc add: renormalize is not idempotent for CRCRLF Bug report https://lore.kernel.org/git/AM0PR02MB56357CC96B702244F3271014E8DC9@AM0PR02MB5635.eurprd02.prod.outlook.com/ noted that a file containing /r/r/n needed renormalising twice. This is by design. Lone CR characters, not paired with an LF, are left unchanged. Note this limitation of the "clean" filter in the documentation. Renormalize was introduced at 9472935d81e (add: introduce "--renormalize", Torsten Bögershausen, 2017-11-16) Signed-off-by: Philip Oakley <philipoakley@iee.email> Reviewed-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 August 2022, 18:26:38 UTC
b15207b Victoria Dye 08 August 2022, 19:07:52 UTC unpack-trees: unpack new trees as sparse directories If 'unpack_single_entry()' is unpacking a new directory tree (that is, one not already present in the index) into a sparse index, unpack the tree as a sparse directory rather than traversing its contents and unpacking each file individually. This helps keep the sparse index as collapsed as possible in cases such as 'git reset --hard' restoring a outside-of-cone directory removed with 'git rm -r --sparse'. Without this patch, 'unpack_single_entry()' will only unpack a directory into the index as a sparse directory (rather than traversing into it and unpacking its files one-by-one) if an entry with the same name already exists in the index. This patch allows sparse directory unpacking without a matching index entry when the following conditions are met: 1. the directory's path is outside the sparse cone, and 2. there are no children of the directory in the index If a directory meets these requirements (as determined by 'is_new_sparse_dir()'), 'unpack_single_entry()' unpacks the sparse directory index entry and propagates the decision back up to 'unpack_callback()' to prevent unnecessary tree traversal into the unpacked directory. Reported-by: Shaoxuan Yuan <shaoxuan.yuan02@gmail.com> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 August 2022, 20:21:50 UTC
9553aa0 Victoria Dye 08 August 2022, 19:07:51 UTC cache.h: create 'index_name_pos_sparse()' Add 'index_name_pos_sparse()', which behaves the same as 'index_name_pos()', except that it does not expand a sparse index to search for an entry inside a sparse directory. 'index_entry_exists()' was originally implemented in 20ec2d034c (reset: make sparse-aware (except --mixed), 2021-11-29) as an alternative to 'index_name_pos()' to allow callers to search for an index entry without expanding a sparse index. However, that particular use case only required knowing whether the requested entry existed, so 'index_entry_exists()' does not return the index positioning information provided by 'index_name_pos()'. This patch implements 'index_name_pos_sparse()' to accommodate callers that need the positioning information of 'index_name_pos()', but do not want to expand the index. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 August 2022, 20:21:50 UTC
56d8a27 Victoria Dye 08 August 2022, 19:07:50 UTC oneway_diff: handle removed sparse directories Update 'do_oneway_diff()' to perform a 'diff_tree_oid()' on removed sparse directories, as it does for added or modified sparse directories (see 9eb00af562 (diff-lib: handle index diffs with sparse dirs, 2021-07-14)). At the moment, this update is unreachable code because 'unpack_trees()' (currently the only way 'oneway_diff()' can be called, via 'diff_cache()') will always traverse trees down to the individual removed files of a deleted sparse directory. A subsequent patch will change this to better preserve a sparse index in other uses of 'unpack_tree()', e.g. 'git reset --hard'. However, making that change without this patch would result in (among other issues) 'git status' printing only the name of a deleted sparse directory, not its contents. To avoid introducing that bug, 'do_oneway_diff()' is updated before modifying 'unpack_trees()'. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 August 2022, 20:21:49 UTC
49ff3cb Victoria Dye 08 August 2022, 19:07:49 UTC checkout: fix nested sparse directory diff in sparse index Add the 'recursive' diff flag to the local changes reporting done by 'git checkout' in 'show_local_changes()'. Without the flag enabled, unexpanded sparse directories will not be recursed into to report the diff of each file's contents, resulting in the reported local changes including "modified" sparse directories. The same issue was found and fixed for 'git status' in 2c521b0e49 (status: fix nested sparse directory diff in sparse index, 2022-03-01) Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 August 2022, 20:21:49 UTC
back to top