Tags: PLESK-COM/git
Tags
gc: add `--expire-to` option From: ZheNing Hu <[email protected]> This commit extends the functionality of `git gc` by adding a new option, `--expire-to=<dir>`. Previously, this feature was implemented in 91badeb (builtin/repack.c: implement `--expire-to` for storing pruned objects, 2022-10-24), which allowing users to specify a directory where unreachable and expired cruft packs are stored during garbage collection. However, users had to run `git repack --cruft --expire-to=<dir>` followed by `git prune` to achieve similar results within `git gc`. By introducing `--expire-to=<dir>` directly into `git gc`, we simplify the process for users who wish to manage their repository's cleanup more efficiently. This change involves passing the `--expire-to=<dir>` parameter through to `git repack`, making it easier for users to set up a backup location for cruft packs that will be pruned. Due to the original `git gc --prune=now` deleting all unreachable objects by passing the `-a` parameter to git repack. With the addition of the `--cruft` and `--expire-to` options, it is necessary to modify this default behavior: instead of deleting these unreachable objects, they should be merged into a cruft pack and collected in a specified directory. Therefore, we do not pass `-a` to the repack command but instead pass `--cruft`, `--expire-to`, and `--cruft-expiration=now` to repack. Signed-off-by: ZheNing Hu <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
docs: indicate http.sslCertType and sslKeyType From: Andrew Carter <[email protected]> These useful config options were added in 0a01d41 but lacked documentation. Signed-off-by: Andrew Carter <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
grep: document negated line-number, column long options From: "D. Ben Knoble" <[email protected]> I set grep.lineNumber and grep.column on in my user .gitconfig; sometimes, when I script over the results from `git grep`, I want no prefixes, only a filename prefix, or only the matched text. I usually comment out the relevant config sections or use `git -c` to tweak them for a single run---why? Because `git help grep` doesn't mention they can be disabled any other way! Intending to add the ability to negate these options, I reviewed builtin/grep.c and learned that OPT_BOOL already provides this feature. Document it for future readers. Borrow "configuration file" language from `--no-color`, since that's my motivating use case. Signed-off-by: D. Ben Knoble <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
gc: add `--expire-to` option From: ZheNing Hu <[email protected]> This commit extends the functionality of `git gc` by adding a new option, `--expire-to=<dir>`. Previously, this feature was implemented in `git repack` (see 91badeb), allowing users to specify a directory where unreachable and expired cruft packs are stored during garbage collection. However, users had to run `git repack --cruft --expire-to=<dir>` followed by `git prune` to achieve similar results within `git gc`. By introducing `--expire-to=<dir>` directly into `git gc`, we simplify the process for users who wish to manage their repository's cleanup more efficiently. This change involves passing the `--expire-to=<dir>` parameter through to `git repack`, making it easier for users to set up a backup location for cruft packs that will be pruned. Note: When git-gc is used with both `--cruft` and `--expire-to`, it does not pass `-a` to git-repack to delete all unreachable objects as `git gc --prune=now` originally did. Instead, it generates a cruft pack in the directory specified by expire-to. Signed-off-by: ZheNing Hu <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
worktree: detect from secondary worktree if main worktree is bare From: Olga Pilipenco <[email protected]> Setup: 1. Have a bare repo with core.bare = true in config.worktree 2. Create a new worktree Behavior: From the secondary worktree the main worktree appears as non-bare. Expected: From the secondary worktree the main worktree should appear as bare. Why current behavior is not good? If the main worktree is detected as not bare it doesn't allow checking out the branch of the main worktree. There are possibly other problems associated with that behavior. Why is it happening? While we're inside the secondary worktree we don't initialize the main worktree's repository with its configuration. How is it fixed? Load actual configs of the main worktree. Also, skip the config loading step if we're already inside the current worktree because in that case we rely on is_bare_repository() to return the correct result. Other solutions considered: Alternatively, instead of incorrectly always using `the_repository` as the main worktree's repository, we can detect and load the actual repository of the main worktree and then use that repository's `is_bare` value extracted from correct configs. However, this approach is a bit riskier and could also affect performance. Since we had the assignment `worktree->repo = the_repository` for a long time already, I decided it's safe to keep it as it is for now; it can be still fixed separately from this change. Real life use case: 1. Have a bare repo 2. Create a worktree from the bare repo 3. In the secondary worktree enable sparse-checkout - this enables extensions.worktreeConfig and keeps core.bare=true setting in config.worktree of the bare worktree 4. The secondary worktree or any other non-bare worktree created won't be able to use branch main (not even once), but it should be able to. Signed-off-by: Olga Pilipenco <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
help: add prompt-yes setting for autocorrect From: Chris Howlett <[email protected]> The help.autocorrect functionality is really useful, saving frustration when a dev fat-fingers a command, and git has a pretty good idea what was originally intended. The config settings are a nice selection, with "prompt" asking the user to confirm that they want to run the assumed command. However, with "prompt", the choice defaults to "No" - that is, hitting return will _not_ run the command. For me at least, if git is confident it knows which command I wanted, it's usually right, and the golden path would be to run the command. Therefore this patch adds "prompt-yes" as a counterpart config setting for help.autocorrect, which does the same as "prompt", but defaults to "Yes" - hitting return will run the assumed command. I have not added any tests because the test suite doesn't have any tests (that I could find) for the "prompt" behaviour - I'm assuming this is because it's hard/impossible to simulate the interactive terminal prompt Signed-off-by: Chris Howlett <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
Doc git commit This series continues the effort of rewriting the documentation with uniformization and better formatting of the man pages. This time, git-commit is processed, taking advantage of previous experiences. Jean-Noël Avila (5): doc: apply new documentation guidelines to git commit doc: the mode param of -u of git commit is optional doc: make more direct explanations in git commit options doc: convert git commit config to new format doc: migrate git-commit manpage secondary files to new format Documentation/config/commit.txt | 25 +-- Documentation/git-commit.txt | 281 +++++++++++++++---------------- Documentation/i18n.txt | 4 +- Documentation/signoff-option.txt | 8 +- builtin/commit.c | 2 +- 5 files changed, 161 insertions(+), 159 deletions(-) base-commit: 1b4e9a5 Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
docs: mention source of tasks in MyFirstContribution From: Rhythm-26 <[email protected]> MyFirstContribution guide lacks clear guidance on where to access list of bugs or feature requests. Improve visibility for contributors on where to find open issues and features that need attention. CC: Johannes Schindelin <[email protected]> Signed-off-by: Rhythm-26 <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
Sanitize sideband channel messages When a clone fails, users naturally turn to the output of the git clone command. To assist in such scenarios, the output includes the messages from the remote git pack-objects process, delivered via what Git calls the "sideband channel." Given that the remote server is, by nature, remote, there is no guarantee that it runs an unmodified Git version. This exposes Git to ANSI escape sequence injection (see CWE-150, https://cwe.mitre.org/data/definitions/150.html), which can corrupt terminal state, hide information, and even insert characters into the input buffer (as if the user had typed those characters). This patch series addresses this vulnerability by sanitizing the sideband channel. It is important to note that the lack of sanitization in the sideband channel is already "exploited" by the Git user community, albeit in well-intentioned ways. For instance, certain server-side hooks use ANSI color sequences in error messages to make them more noticeable during intentional failed fetches, e.g. as seen at https://github.com/kikeonline/githook-explode and https://github.com/arosien/bart/blob/HEAD/hooks/post-receive.php To accommodate such use cases, Git will allow ANSI color sequences to pass through by default, while presenting all other ASCII control characters in a common form (e.g., presenting the ESC character as ^[). This vulnerability was reported to the Git security mailing list in early November, along with these fixes, as part of an iteration of the patches that led to the coordinated security release on Tuesday, January 14th, 2025. While Git for Windows included these fixes in v2.47.1(2), the consensus, apart from one reviewer, was not to include them in Git's embargoed versions. The risk was considered too high to disrupt existing scenarios that depend on control characters received via the sideband channel being sent verbatim to the user's terminal emulator. Several reviewers suggested advising terminal emulator writers about these "quality of implementation issues" instead. I was quite surprised by this approach, as it seems overly optimistic to assume that terminal emulators could distinguish between control characters intentionally sent by Git and those unintentionally relayed from the remote server. Please note that this patch series applies cleanly on top of v2.47.2. To apply it cleanly on top of v2.40.4 (the oldest of the most recently serviced security releases), the calls to test_grep need to be replaced with calls to test_i18ngrep, and the calls to git_config_get_string_tmp() need to be replaced with calls to git_config_get_string(). Johannes Schindelin (3): sideband: mask control characters sideband: introduce an "escape hatch" to allow control characters sideband: do allow ANSI color sequences by default Documentation/config.txt | 2 + Documentation/config/sideband.txt | 16 ++++++ sideband.c | 78 ++++++++++++++++++++++++++++- t/t5409-colorize-remote-messages.sh | 30 +++++++++++ 4 files changed, 124 insertions(+), 2 deletions(-) create mode 100644 Documentation/config/sideband.txt base-commit: e1fbebe Submitted-As: https://lore.kernel.org/git/[email protected]
docs: add vim syntax modeline [RFC] From: M Hickford <[email protected]> Git documentation is written in AsciiDoc. This format is easily mistaken for the pervasive Markdown. Add a vim modeline to help editors identify the format and provide syntax highlighting, rendering and autocomplete. This makes editing the documentation easier for prospective contributors. This is particularly important because new contributors often start with documentation changes. An alternative could be to move the modeline up or down the file (the location is not important). A simpler alternative could be to rename files *.adoc. This would have the advantage of being recognised by even more tools. Signed-off-by: M Hickford <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
PreviousNext