Tags: gitgitgadget/git
Tags
merge-ours: sparse-index integration This short series teaches merge-ours to work with a sparse index. Patch 1 is a preparatory cleanup that converts merge-ours away from the_repository global, using the repo parameter instead. Patch 2 adds the actual sparse-index integration and tests. Because merge-ours is invoked as a subprocess by git merge -s ours and never previously read config, the sparse-checkout globals remained unset, causing the index to be expanded unconditionally. A repo_config() call fixes this. Developed with AI assistance (Claude). Sam Bostock (2): merge-ours: drop USE_THE_REPOSITORY_VARIABLE merge-ours: integrate with sparse-index builtin/merge-ours.c | 15 +++++++++------ t/t1092-sparse-checkout-compatibility.sh | 14 ++++++++++++++ 2 files changed, 23 insertions(+), 6 deletions(-) base-commit: b2826b5 Submitted-As: https://lore.kernel.org/git/pull.2189.git.git.1770345124.gitgitgadget@gmail.com
doc: some more synopsis conversions and fixes This time, git-show and git-submodule are converted. Some mistakes on previous work were also spotted and fixed. Changes since V1: * fix mistakes spotted by Kristoffer Haugsbakk Changes since V2: * more fixes Changes since V3: * again more fixes, origin and HEAD Jean-Noël Avila (4): doc: convert git-submodule to synopsis style doc: finalize git-clone documentation conversion to synopsis style doc: fix some style issues in git-clone and for-each-ref-options doc: convert git-show to synopsis style Documentation/asciidoc.conf.in | 6 + Documentation/for-each-ref-options.adoc | 4 +- Documentation/git-clone.adoc | 54 ++-- Documentation/git-show.adoc | 16 +- Documentation/git-submodule.adoc | 395 ++++++++++++------------ Documentation/pretty-formats.adoc | 169 +++++----- Documentation/ref-storage-format.adoc | 4 +- 7 files changed, 341 insertions(+), 307 deletions(-) base-commit: d8af7ca Submitted-As: https://lore.kernel.org/git/pull.2036.v4.git.1770351146.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2036.git.1769202903.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2036.v2.git.1769462744.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2036.v3.git.1770138215.gitgitgadget@gmail.com
doc: fix repo_config documentation reference From: SoutrikDas <valusoutrik@gmail.com> Since documentation was moved from Documenation/ technical/api-config to inside the config.h This might help newcomers, by pointing them to the right place to get documentation about repo_config Signed-off-by: SoutrikDas <valusoutrik@gmail.com> Submitted-As: https://lore.kernel.org/git/pull.2187.git.git.1770293021383.gitgitgadget@gmail.com
trace2: add macOS and Windows process ancestry tracing In 353d3d7 (trace2: collect Windows-specific process information) Windows-specific process ancestry information was added as a data_json event to TRACE2. Furthermore in 2f732bf (tr2: log parent process name) similar functionality was added for Linux-based systems, using procfs. Let's teach Git on macOS to also gather process ancestry information, and emit it as a cmd_ancestry TRACE2 event. Furthermore, let's refactor the Windows implementation to align with the Linux and macOS versions - by emitting the ancestry information as a cmd_ancestry event. We keep the older, custom data_json event type on Windows for compatibility for consumers of the TRACE2 data that use the older event. Thanks, Matthew Matthew John Cheetham (4): trace2: add macOS process ancestry tracing build: include procinfo.c impl for macOS trace2: refactor Windows process ancestry trace2 event trace2: emit cmd_ancestry data for Windows compat/darwin/procinfo.c | 99 ++++++++++++++++++++++++ compat/win32/trace2_win32_process_info.c | 58 ++++++++------ config.mak.uname | 2 + contrib/buildsystems/CMakeLists.txt | 2 + meson.build | 2 + 5 files changed, 138 insertions(+), 25 deletions(-) create mode 100644 compat/darwin/procinfo.c base-commit: 9a2fb14 Submitted-As: https://lore.kernel.org/git/pull.2040.git.1770307510.gitgitgadget@gmail.com
[RFC] config-batch: a new builtin for tools querying config
This RFC explores a new git config-batch builtin that allows tools to
interact with Git's config data with multiple queries using a single
process. This is an orthogonal alternative to the effort to create a stable,
linkable config API. Both approaches have different strengths.
My main motivation is the performance of git-credential-manager on Windows
platforms as it can call git config get dozens of times. At 150-200ms per
execution, that adds up significantly, leading to multiple seconds just to
load a credential that already exists. I believe that there are other
benefits to having this interface available, but I can't recall any
specifics at the moment.
This RFC adds git config-batch with a protocol over stdin/stdout for
executing multiple config queries. The implementation has a limited set of
potential queries, but also creates a model for compatibility for tools to
automatically adapt to different Git versions.
I'm submitting this as an RFC before I've polished all of the details
because I want to make sure I'm going down a good direction. Please focus
feedback in these questions:
* Is this a worthwhile feature to add to Git?
* Is this a reasonable protocol for stdin/stdout?
* How can we structure the code to make it easier to contribute new
commands in the future?
* This seems like a place where parallel contributions can be made once the
baseline is implemented. Is there interest in further contributions to
expand the commands?
This RFC adds the following commands over stdin:
1. help lists the available commands, giving the caller an understanding of
what is available in this Git version.
2. get loads a value for a given key within a certain scope, with optional
value patterns.
3. set assigns a key-value pair in a given scope.
4. unset removes a key-value pair in a given scope with optional value
patterns.
Each command has an associated version, in case we need to expand or alter
the functionality in the future. This includes the potential to deprecate
and remove certain versions that we no longer want to support, such as
replacing set version 1 with a version 2 and making version 1 no longer
available. I do hope that we will mostly be able to move with new command
names, such as a set-all command including the options for git config set
--all ... instead of increasing the version of the set command.
There is a -z option that changes the command interface to use
NUL-terminated strings. Two NULs specify a command boundary, which promotes
compatibility with a caller that sends an unknown command. However, this
means that we cannot specify an empty string as a token within a command
unless we add more data. This format uses <N>:<string> to provide the
integer <N> which specifies the length of <string>. This is a little
cumbersome, but the format is intended for tools, not humans.
I have a test integration with git-credential-manager available [1] for
testing. This includes a model for interacting with git config-batch in a
compatible way that will respond to certain features not being available:
1. If git config-batch fails immediately, then all queries are handled by
git config.
2. If git config-batch starts without failure, then the first query is for
the help command.
3. As queries come to the config system, the query is checked against the
available commands advertised by git config-batch. If the appropriate
command is available, then the query is made in that process. If not,
then the query uses the existing git config command.
One thing that I think would be valuable to include is a reload command that
signals that the git config-batch process should reload the configset into
memory due to config manipulations in other processes, especially while git
config-batch doesn't have all capabilities from git config. I'll include
that in the first version for review, if this RFC leads to positive support.
[1] git-ecosystem/git-credential-manager#2245
I have a few concerns with this implementation that I'd like to improve
before submitting a version for full review. I list them here so you can see
the flaws that I already see, but also so you can add to this list:
* We need a reload command (as mentioned above).
* The tests need to include a submodule and submodule-level config.
* When specifying the local scope to the get command, the matched value
does not include worktree or submodule config in the same way that git
config get --local <key> would.
* The token-parsing API in this helper is still too complicated to use. I
should create parsing tooling similar to the parse-opts API so each
command could specify its use of positional values and optional
arguments.
* The use of arg:<arg> to specify an optional argument creates the
inability to submit a value that starts with arg:. Consider alternative
ways to specify arguments or to specify that the remaining data in the
command (including spaces) is a final positional argument.
* In general, I found myself implementing behavior based on the deprecated
forms of git config that use the --get or --unset style arguments instead
of git config (set|unset|get) subcommands. It's worth making sure that
any references to equivalent git config commands use the new modes.
* I need to add an --[no-]includes option as a command-line argument that
signals whether include sections should be followed. I don't believe this
should be specified on a per-command basis, but I'm open to suggestions.
* I have an early draft of a technical document detailing the plan for this
builtin. It has some lists of intended future commands that have not been
implemented. This would also be a good place to document any parsing APIs
built to help contributors adding to this builtin.
Thanks, -Stolee
Derrick Stolee (11):
config-batch: basic boilerplate of new builtin
config-batch: create parse loop and unknown command
config-batch: implement get v1
config-batch: create 'help' command
config-batch: add NUL-terminated I/O format
docs: add design doc for config-batch
config: extract location structs from builtin
config-batch: pass prefix through commands
config-batch: add 'set' v1 command
t1312: create read/write test
config-batch: add unset v1 command
.gitignore | 1 +
Documentation/git-config-batch.adoc | 214 ++++++
Documentation/meson.build | 1 +
Documentation/technical/config-batch.adoc | 70 ++
Makefile | 1 +
builtin.h | 7 +
builtin/config-batch.c | 772 ++++++++++++++++++++++
builtin/config.c | 117 +---
command-list.txt | 1 +
config.c | 116 ++++
config.h | 26 +
git.c | 1 +
meson.build | 1 +
t/meson.build | 1 +
t/t1312-config-batch.sh | 372 +++++++++++
15 files changed, 1592 insertions(+), 109 deletions(-)
create mode 100644 Documentation/git-config-batch.adoc
create mode 100644 Documentation/technical/config-batch.adoc
create mode 100644 builtin/config-batch.c
create mode 100755 t/t1312-config-batch.sh
base-commit: 83a69f1
Submitted-As: https://lore.kernel.org/git/pull.2033.git.1770214803.gitgitgadget@gmail.com
clone: fix segfault when using --revision and v0/v1 protocol From: Nitro Cao <jaycecao520@gmail.com> When `git clone` is used with `--revision` and the protocol version is v0 or v1, the client segfaults if the revision does not specify a peer reference (e.g. `--revision master` instead of `--revision refs/heads/master:master`). This occurs because `update_remote_refs()` assumes that if `remote_head_points_at` is set, `remote_head_points_at->peer_ref` is also valid. However, for v0/v1 protocols, all references are fetched without filtering, and if the revision lacks a peer reference, `peer_ref` remains NULL. Add a check for `remote_head_points_at->peer_ref` before dereferencing it to prevent the segmentation fault. Signed-off-by: Nitro Cao <jaycecao520@gmail.com> Submitted-As: https://lore.kernel.org/git/pull.2185.v2.git.git.1770119773541.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2185.git.git.1769937818682.gitgitgadget@gmail.com
doc: some more synopsis conversions and fixes This time, git-show and git-submodule are converted. Some mistakes on previous work were also spotted and fixed. Changes since V1: * fix mistakes spotted by Kristoffer Haugsbakk Jean-Noël Avila (4): doc: convert git-submodule to synopsis style doc: finalize git-clone documentation conversion to synopsis style doc: fix some style issues in git-clone and for-each-ref-options doc: convert git-show to synopsis style Documentation/asciidoc.conf.in | 6 + Documentation/for-each-ref-options.adoc | 4 +- Documentation/git-clone.adoc | 54 ++-- Documentation/git-show.adoc | 16 +- Documentation/git-submodule.adoc | 389 ++++++++++++------------ Documentation/pretty-formats.adoc | 169 +++++----- Documentation/ref-storage-format.adoc | 4 +- 7 files changed, 338 insertions(+), 304 deletions(-) base-commit: d8af7ca Submitted-As: https://lore.kernel.org/git/pull.2036.v3.git.1770138215.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2036.git.1769202903.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2036.v2.git.1769462744.gitgitgadget@gmail.com
Sanitize sideband channel messages Git's sideband channel passes server output directly to the client terminal without sanitizing it, creating an ANSI escape sequence injection vulnerability (CWE-150 [https://cwe.mitre.org/data/definitions/150.html]). A malicious or compromised server can corrupt terminal state, obscure information, or inject characters into the terminal's input buffer (which the terminal will interpret as if the user had typed them). Git users have no mechanism to distinguish between Git's legitimate output and content displayed (or hidden) via attack sequences. This series aims to fix the vulnerability by sanitizing control characters in the sideband output. To address concerns about existing hacks that exploit Git's lack of sanitizing, this security fix will only kick in with Git v3.0, where the default will change to pass ANSI color sequences (SGR codes) through by default, since server-side hooks exist that use these for visibility (e.g. https://github.com/kikeonline/githook-explode). By default, all other control characters will be rendered in caret notation (e.g., ESC becomes ^[). Users who need different behavior get configuration options: sideband.allowControlCharacters provides an escape hatch for environments that require raw passthrough. The defaults in Git v3.0 will be secure. This series applies cleanly on v2.53.0. Changes since v3: * Targeting maint-2.53 now instead of maint-2.47. * Turned the "safe by default" behavior into a breaking change that will be in effect in Git v3.0. Changes since v2: * Added curly brackets around a single-line if clause. * Enclosed the values in the documentation within backticks. * Aligned the enum values for better readability. * Added support for sideband.<url>.allowControlCharacters (à la http.<url>.*) on top of sideband.allowControlCharacters. Changes since v1: * Applied the suggestions by Phillip and brian. * Rebased onto v2.47.3. * Added more categories of ANSI Escape sequences that can be enabled (but that are off by default because they could be used to hide information). Johannes Schindelin (6): sideband: mask control characters sideband: introduce an "escape hatch" to allow control characters sideband: do allow ANSI color sequences by default sideband: add options to allow more control sequences to be passed through sideband: offer to configure sanitizing on a per-URL basis sideband: delay sanitizing by default to Git v3.0 Documentation/config.adoc | 2 + Documentation/config/sideband.adoc | 39 ++++++ sideband.c | 185 +++++++++++++++++++++++++++- sideband.h | 14 +++ t/t5409-colorize-remote-messages.sh | 100 +++++++++++++++ transport.c | 3 + 6 files changed, 341 insertions(+), 2 deletions(-) create mode 100644 Documentation/config/sideband.adoc base-commit: 67ad421 Submitted-As: https://lore.kernel.org/git/pull.1853.v4.git.1770113882.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1853.git.1736878772.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1853.v2.git.1765981422.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1853.v3.git.1768602373.gitgitgadget@gmail.com
fix(clone): segment fault when using --revision and protocol v0/v1
From: Nitro Cao <jaycecao520@gmail.com>
git clone command would segment fault when satisfying the following
conditions at the same time:
- Use HTTP protocol v0 or v1 to interact with remote servers.
- The value of `--revision` doesn't specify the peer reference, like
`--revision master` instead of `--revision refs/heads/master:master`
When using protocol v2, git client can use `ref-prefix` param of
`ls-refs` command to fetch wanted references based on `--revision`.
But for protocol v0/v1, git client just fetch all references and
doesn't filter them.
In this case, the value of `remote_head` variable is not NULL,
which leads to the value of `remote_head_points_at` not NULL too.
But we don't specify the peer reference in `--revsion`,
`remote_head_points_at->peer_ref` would be NULL. So git client would
boom when `update_remote_refs`.
Signed-off-by: Nitro Cao <jaycecao520@gmail.com>
Submitted-As: https://lore.kernel.org/git/pull.2185.git.git.1769937818682.gitgitgadget@gmail.com
PreviousNext