aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-08-19doc: git-add: simplify discussion of ignored filesJulia Evans1-6/+4
- Mention the --force option earlier - Remove the explanation of shell globbing vs git's internal glob system, since users are confused by it and there's a clearer discussion in the EXAMPLES section. Signed-off-by: Julia Evans <julia@jvns.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-19doc: git-add: clarify intro & add an exampleJulia Evans1-12/+12
- Add a basic example of how "git add" is normally used - It's not technically true that you *must* use the `add` command to add changes before running `git commit`, because `git commit -a` exists. Instead say that you *can* use the `add` command. - Mention early on that "index" is another word for "staging area", since Git very rarely uses the word "index" in its output (`git status`) uses the term "staged", and many Git users are unfamiliar with the term "index" - Remove "It typically adds" (it's not clear what "typically" means), and instead mention that `git add -p` can be used to add partial contents - Currently the introduction is somewhat repetitive ("to prepare the content staged for the next commit" ... "this snapshot that is taken as the contents of the next commit."), replace with a single sentence ("The "index" [...] is where Git stores the contents of the next commit.") Signed-off-by: Julia Evans <julia@jvns.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-17repo: add the --format flagLucas Seiki Oshiro1-7/+33
Add the --format flag to git-repo-info. By using this flag, the users can choose the format for obtaining the data they requested. Given that this command can be used for generating input for other applications and for being read by end users, it requires at least two formats: one for being read by humans and other for being read by machines. Some other Git commands also have two output formats, notably git-config which was the inspiration for the two formats that were chosen here: - keyvalue, where the retrieved data is printed one per line, using = for delimiting the key and the value. This is the default format, targeted for end users. - nul, where the retrieved data is separated by NUL characters, using the newline character for delimiting the key and the value. This format is targeted for being read by machines. Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Justin Tobler <jltobler@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Mentored-by: Karthik Nayak <karthik.188@gmail.com> Mentored-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-17repo: add the field layout.shallowLucas Seiki Oshiro1-0/+3
This commit is part of the series that introduces the new subcommand git-repo-info. The flag `--is-shallow-repository` from git-rev-parse is used for retrieving whether the repository is shallow. This way, it is used for querying repository metadata, fitting in the purpose of git-repo-info. Then, add a new field `layout.shallow` to the git-repo-info subcommand containing that information. Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Justin Tobler <jltobler@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Mentored-by: Karthik Nayak <karthik.188@gmail.com> Mentored-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-17repo: add the field layout.bareLucas Seiki Oshiro1-0/+3
This commit is part of the series that introduces the new subcommand git-repo-info. The flag --is-bare-repository from git-rev-parse is used for retrieving whether the current repository is bare. This way, it is used for querying repository metadata, fitting in the purpose of git-repo-info. Then, add a new field layout.bare to the git-repo-info subcommand containing that information. Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Justin Tobler <jltobler@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Mentored-by: Karthik Nayak <karthik.188@gmail.com> Mentored-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-17repo: add the field references.formatLucas Seiki Oshiro1-0/+20
This commit is part of the series that introduces the new subcommand git-repo-info. The flag `--show-ref-format` from git-rev-parse is used for retrieving the reference format (i.e. `files` or `reftable`). This way, it is used for querying repository metadata, fitting in the purpose of git-repo-info. Add a new field `references.format` to the repo-info subcommand containing that information. Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Justin Tobler <jltobler@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Mentored-by: Karthik Nayak <karthik.188@gmail.com> Mentored-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-17repo: declare the repo commandLucas Seiki Oshiro2-0/+33
Currently, `git rev-parse` covers a wide range of functionality not directly related to parsing revisions, as its name suggests. Over time, many features like parsing datestrings, options, paths, and others were added to it because there wasn't a more appropriate command to place them. Create a new Git command called `repo`. `git repo` will be the main command for obtaining the information about a repository (such as metadata and metrics). Also declare a subcommand for `repo` called `info`. `git repo info` will bring the functionality of retrieving repository-related information currently returned by `rev-parse`. Add the required documentation and build changes to enable usage of this subcommand. Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Justin Tobler <jltobler@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Mentored-by: Karthik Nayak <karthik.188@gmail.com> Mentored-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-14count-objects: document count-objects packDaniele Sassoli1-0/+2
0bdaa12169b (git-count-objects.txt: describe each line in -v output, 2013-02-08) forgot to include `packs`. Signed-off-by: Daniele Sassoli <danielesassoli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-12send-email: enable copying emails to an IMAP folder without actually sending ↵Aditya Garg2-0/+15
them `git imap-send` was built on the idea of copying emails to an IMAP folder like drafts, and sending them later using an email client. Currently the only way to do it is by piping output of `git format-patch` to IMAP send. Add another way to do it by using `git send-email` with the `--use-imap-only` or `sendmail.useImapOnly` option. This allows users to use the advanced features of `git send-email` like tweaking Cc: list programmatically, compose the cover letter, etc. and then send the well formatted emails to an IMAP folder using `git imap-send`. While at it, use `` instead of '' for --smtp-encryption ssl in help section of `git send-email`. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-12send-email: add ability to send a copy of sent emails to an IMAP folderAditya Garg2-0/+13
Some email providers like Apple iCloud Mail do not support sending a copy of sent emails to the "Sent" folder if SMTP server is used. As a workaround, various email clients like Thunderbird which rely on SMTP, use IMAP to send a copy of sent emails to the "Sent" folder. Something similar can be done if sending emails via `git send-email`, by using the `git imap-send` command to send a copy of the sent email to an IMAP folder specified by the user. Add this functionality to `git send-email` by introducing a new configuration variable `sendemail.imapfolder` and command line option `--imap-folder` which specifies the IMAP folder to send a copy of the sent emails to. If specified, a copy of the sent emails will be sent by piping the emails to `git imap-send` command, after all emails are sent via SMTP and the SMTP server has been closed. Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-12docs: remove stray bracket from git-clone synopsisKnut Harald Ryager1-1/+1
The synopsis section has an extra closing bracket, like this: [--filter=<filter>] [--also-filter-submodules]] The extra one is not the one at the end of this line; it is the one after "...=<filter>". The "--also-filter-submodules" option was added by f05da2b4 (clone, submodule: pass partial clone filters to submodules, 2022-02-04). Because it makes sense only when used with the "--filter=<filter>" option, these two options are enclosed in a pair of brackets. The extra one was added by 76880f05 (doc: git-clone: apply new documentation formatting guidelines, 2024-03-29) by mistake. Remove the extra and incorrect closing bracket, so that the line reads: [--filter=<filter> [--also-filter-submodules]] Signed-off-by: Knut Harald Ryager <e-k-nut@hotmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-11doc lint: check that synopsis manpages have synopsis inlinesJean-Noël Avila3-11/+17
When switching manpages to the synopsis style, the description lists of options need to be switched to inline synopsis for proper formatting. This is done by enclosing the option name in double backticks, e.g. `--option`. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-11doc:git-for-each-ref: fix styling and typosJean-Noël Avila1-132/+132
This commit fixes the synopsis syntax and changes the wording of a few descriptions to be more consistent with the rest of the documentation. It is a prepartion for the next commit that checks that synopsis style is applied consistently across a manual page. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-11doc: check for absence of the form --[no-]parameterJean-Noël Avila36-78/+159
For better searchability, this commit adds a check to ensure that parameters expressed in the form of `--[no-]parameter` are not used in the documentation. In the place of such parameters, the documentation should list two separate parameters: `--parameter` and `--no-parameter`. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-11doc: check for absence of multiple terms in each entry of desc listJean-Noël Avila6-6/+50
For simplifying automated translation of the documentation, it is better to only present one term in each entry of a description list of options. This is because most of these terms can automatically be marked as notranslatable. Also, due to portability issues, the script generate-configlist.sh can no longer insert newlines in the output. However, the result is that it no longer correctly handles multiple terms in a single entry of definition lists. As a result, we now check that these entries do not exist in the documentation. Reviewed-by: Collin Funk <collin.funk1@gmail.com> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-11doc: check well-formedness of delimited sectionsJean-Noël Avila13-4/+79
Having an empty line before each delimited sections is not required by asciidoc, but it is a safety measure that prevents generating malformed asciidoc when generating translated documentation. When a delimited section appears just after a paragraph, the asciidoc processor checks that the length of the delimited section header is different from the length of the paragraph. If it is not, the asciidoc processor will generate a title. In the original English documentation, this is not a problem because the authors always check the output of the asciidoc processor and fix the length of the delimited section header if it turns out to be the same as the paragraph length. However, this is not the case for translations, where the authors have no way to check the length of the delimited section header or the output of the asciidoc processor. This can lead to a section title that is not intended. Indeed, this test also checks that titles are correctly formed, that is, the length of the underline is equal to the length of the title (otherwise it would not be a title but a section header). Finally, this test checks that the delimited section are terminated within the same file. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-11doc: test linkgit macros for well-formednessJean-Noël Avila2-1/+8
Some readers of man pages have reported that they found malformed linkgit macros in the documentation (absence or bad spelling). Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-08doc: git-log: fix description listKristoffer Haugsbakk1-2/+2
b27be108c89 (doc: git-log: convert log config to new doc format, 2025-07-07) intended to convert a paragraph describing the different options for `log.decorate` into a description list. But the literal block syntax was used by mistake. Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-07diff: teach tree-diff a max-depth parameterJeff King1-0/+28
When you are doing a tree-diff, there are basically two options: do not recurse into subtrees at all, or recurse indefinitely. While most callers would want to always recurse and see full pathnames, some may want the efficiency of looking only at a particular level of the tree. This is currently easy to do for the top-level (just turn off recursion), but you cannot say "show me what changed in subdir/, but do not recurse". This patch adds a max-depth parameter which is measured from the closest pathspec match, so that you can do: git log --raw --max-depth=1 -- a/b/c and see the raw output for a/b/c/, but not those of a/b/c/d/ (instead of the raw output you would see for a/b/c/d). Co-authored-by: Toon Claes <toon@iotcl.com> Signed-off-by: Toon Claes <toon@iotcl.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-07Git 2.51-rc1v2.51.0-rc1Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-07Documentation/RelNotes/2.51.0: improve wording for a couple entriesPatrick Steinhardt1-5/+5
Improve wording and fix typos for a couple entries part of the Git 2.51 release notes. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-06builtin/reflog: implement subcommand to write new entriesPatrick Steinhardt1-0/+7
While we provide a couple of subcommands in git-reflog(1) to remove reflog entries, we don't provide any to write new entries. Obviously this is not an operation that really would be needed for many use cases out there, or otherwise people would have complained that such a command does not exist yet. But the introduction of the "reftable" backend changes the picture a bit, as it is now basically impossible to manually append a reflog entry if one wanted to do so due to the binary format. Plug this gap by introducing a simple "write" subcommand. For now, all this command does is to append a single new reflog entry with the given object IDs and message to the reflog. More specifically, it is not yet possible to: - Write multiple reflog entries at once. - Insert reflog entries at arbitrary indices. - Specify the date of the reflog entry. - Insert reflog entries that refer to nonexistent objects. If required, those features can be added at a future point in time. For now though, the new command aims to fulfill the most basic use cases while being as strict as possible when it comes to verifying parameters. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-06builtin/reflog: improve grouping of subcommandsPatrick Steinhardt1-30/+31
The way subcommands of git-reflog(1) are laid out does not make any immediate sense. Reorder them such that read-only subcommands precede writing commands for a bit more structure. Furthermore, move the "expire" subcommand last. This prepares for a subsequent change where we are about to introduce a new "write" command to append reflog entries. Like this, the writing subcommands are ordered such that those affecting a single reflog come before those spanning across all reflogs. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-06Documentation/git-reflog: convert to use synopsis typePatrick Steinhardt1-19/+19
With 974cdca345c (doc: introduce a synopsis typesetting, 2024-09-24) we have introduced a new synopsis type that simplifies the rules for typesetting a command's synopsis. Convert the git-reflog(1) documentation to use it. While at it, convert the list of options to use backticks. This is done to appease an upcoming new linter that mandates the use of backticks when using the synopsis type. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-05A bit more after -rc0Junio C Hamano1-0/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-05Merge branch 'kj/renamed-submodule'Junio C Hamano1-0/+7
The case where a new submodule takes a path where used to be a completely different subproject is now dealt a bit better than before. * kj/renamed-submodule: fixup! submodule: skip redundant active entries when pattern covers path fixup! submodule: prevent overwriting .gitmodules on path reuse submodule: skip redundant active entries when pattern covers path submodule: prevent overwriting .gitmodules on path reuse
2025-08-05builtin/refs: add list subcommandMeet Soni1-0/+16
Git's reference management is distributed across multiple commands. As part of an ongoing effort to consolidate and modernize reference handling, introduce a `list` subcommand under the `git refs` umbrella as a replacement for `git for-each-ref`. Implement `cmd_refs_list` by having it call the `for_each_ref_core()` helper function. This helper was factored out of the original `cmd_for_each_ref` in a preceding commit, allowing both commands to share the same core logic as independent peers. Add documentation for the new command. The man page leverages the shared options file, created in a previous commit, by using the AsciiDoc `include::` macro to ensure consistency with git-for-each-ref(1). Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: shejialuo <shejialuo@gmail.com> Mentored-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Meet Soni <meetsoni3017@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-05doc: factor out common optionMeet Soni2-88/+89
In preparation for adding documentation for `git refs list`, factor out the common options from the `git-for-each-ref` man page into a shareable file `for-each-ref-options.adoc` and update `git-for-each-ref.adoc` to use an `include::` macro. This change is a pure refactoring and results in no change to the final rendered documentation for `for-each-ref`. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: shejialuo <shejialuo@gmail.com> Mentored-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Meet Soni <meetsoni3017@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-04Git 2.51-rc0v2.51.0-rc0Junio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-04Merge branch 'kh/doc-fast-import-historical'Junio C Hamano1-1/+1
Doc update. * kh/doc-fast-import-historical: doc: fast-import: contextualize the hardware cost
2025-08-04Merge branch 'jc/doc-release-vs-clear'Junio C Hamano1-2/+3
Doc update. * jc/doc-release-vs-clear: CodingGuidelines: clarify that S_release() does not reinitialize
2025-08-04Merge branch 'js/mingw-fixes'Junio C Hamano1-6/+0
Windows fixes. * js/mingw-fixes: mingw: support Windows Server 2016 again mingw_rename: support ReFS on Windows 2022 mingw: drop Windows 7-specific work-around mingw_open_existing: handle directories better
2025-08-04Merge branch 'lm/add-p-context'Junio C Hamano7-0/+22
"git add/etc -p" now honor the diff.context configuration variable, and also they learn to honor the -U<n> command-line option. * lm/add-p-context: add-patch: add diff.context command line overrides add-patch: respect diff.context configuration t: use test_config in t4055 t: use test_grep in t3701 and t4055
2025-08-04Merge branch 'ps/config-wo-the-repository'Junio C Hamano1-1/+1
The config API had a set of convenience wrapper functions that implicitly use the_repository instance; they have been removed and inlined at the calling sites. * ps/config-wo-the-repository: (21 commits) config: fix sign comparison warnings config: move Git config parsing into "environment.c" config: remove unused `the_repository` wrappers config: drop `git_config_set_multivar()` wrapper config: drop `git_config_get_multivar_gently()` wrapper config: drop `git_config_set_multivar_in_file_gently()` wrapper config: drop `git_config_set_in_file_gently()` wrapper config: drop `git_config_set()` wrapper config: drop `git_config_set_gently()` wrapper config: drop `git_config_set_in_file()` wrapper config: drop `git_config_get_bool()` wrapper config: drop `git_config_get_ulong()` wrapper config: drop `git_config_get_int()` wrapper config: drop `git_config_get_string()` wrapper config: drop `git_config_get_string()` wrapper config: drop `git_config_get_string_multi()` wrapper config: drop `git_config_get_value()` wrapper config: drop `git_config_get_value()` wrapper config: drop `git_config_get()` wrapper config: drop `git_config_clear()` wrapper ...
2025-08-04Merge branch 'kn/for-each-ref-skip-updates'Junio C Hamano1-6/+7
Code clean-up. * kn/for-each-ref-skip-updates: ref-filter: use REF_ITERATOR_SEEK_SET_PREFIX instead of '1' t6302: add test combining '--start-after' with '--exclude' for-each-ref: reword the documentation for '--start-after' for-each-ref: fix documentation argument ordering ref-cache: use 'size_t' instead of int for length
2025-08-04Merge branch 'jt/switch-restore-no-longer-experimental'Junio C Hamano2-4/+0
"git switch" and "git restore" are declared to be no longer experimental. * jt/switch-restore-no-longer-experimental: builtin: unmark git-switch and git-restore as experimental
2025-08-03The seventeenth batch, just before -rc0Junio C Hamano1-0/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-03Merge branch 'kn/for-each-ref-skip'Junio C Hamano1-1/+9
"git for-each-ref" learns "--start-after" option to help applications that want to page its output. * kn/for-each-ref-skip: ref-cache: set prefix_state when seeking for-each-ref: introduce a '--start-after' option ref-filter: remove unnecessary else clause refs: selectively set prefix in the seek functions ref-cache: remove unused function 'find_ref_entry()' refs: expose `ref_iterator` via 'refs.h'
2025-08-03mingw: drop Windows 7-specific work-aroundJohannes Schindelin1-6/+0
In ac33519ddfa8 (mingw: restrict file handle inheritance only on Windows 7 and later, 2019-11-22), I introduced code to safe-guard the defense-in-depth handling that restricts handles' inheritance so that it would work with Windows 7, too. Let's revert this patch: Git for Windows dropped supporting Windows 7 (and Windows 8) directly after Git for Windows v2.46.2. For full details, see https://gitforwindows.org/requirements#windows-version. Actually, on second thought: revert only the part that makes this handle inheritance restriction logic optional and that suggests to open a bug report if it fails, but keep the fall-back to try again without said logic: There have been a few false positives over the past few years (where the warning was triggered e.g. because Defender was still accessing a file that Git wanted to overwrite), and the fall-back logic seems to have helped occasionally in such situations. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-01The sixteenth batchJunio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-01Merge branch 'ly/pull-autostash'Junio C Hamano1-0/+16
"git pull" learned to pay attention to pull.autostash configuration variable, which overrides rebase/merge.autostash. * ly/pull-autostash: pull: add pull.autoStash config option
2025-08-01Merge branch 'jc/document-test-balloons-in-flight'Junio C Hamano1-0/+8
To help our developers, document what C99 language features are being considered for adoption, in addition to what past experiments have already decided. * jc/document-test-balloons-in-flight: CodingGuidelines: document test balloons in flight
2025-08-01Merge branch 'ag/imap-send-list-folders-doc'Junio C Hamano1-0/+28
Document recently added "git imap-send --list" with an example. * ag/imap-send-list-folders-doc: docs: explain how to use `git imap-send --list` command to get a list of available folders
2025-08-01doc: fast-import: contextualize the hardware costKristoffer Haugsbakk1-1/+1
6e411d20440 (Initial draft of fast-import documentation., 2007-02-05) pointed out how much time a fast-import took on some hardware with a specific cost. Let’s further point out that this experiment was done in 2007. So modern hardware should have no issues with such a repo. Also move the parenthetical to the end now that it contains four words. Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-08-01CodingGuidelines: clarify that S_release() does not reinitializeJunio C Hamano1-2/+3
In the section for naming various API functions, the fact that S_release() only releases the resources without preparing the structure for immediate reuse becomes only apparent when you readentries for S_release() and S_clear(). Clarify the description of S_release() a bit to make the entry self sufficient. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-07-31Merge branch 'ps/config-wo-the-repository' into ↵Junio C Hamano1-1/+1
pw/3.0-commentchar-auto-deprecation * ps/config-wo-the-repository: (21 commits) config: fix sign comparison warnings config: move Git config parsing into "environment.c" config: remove unused `the_repository` wrappers config: drop `git_config_set_multivar()` wrapper config: drop `git_config_get_multivar_gently()` wrapper config: drop `git_config_set_multivar_in_file_gently()` wrapper config: drop `git_config_set_in_file_gently()` wrapper config: drop `git_config_set()` wrapper config: drop `git_config_set_gently()` wrapper config: drop `git_config_set_in_file()` wrapper config: drop `git_config_get_bool()` wrapper config: drop `git_config_get_ulong()` wrapper config: drop `git_config_get_int()` wrapper config: drop `git_config_get_string()` wrapper config: drop `git_config_get_string()` wrapper config: drop `git_config_get_string_multi()` wrapper config: drop `git_config_get_value()` wrapper config: drop `git_config_get_value()` wrapper config: drop `git_config_get()` wrapper config: drop `git_config_clear()` wrapper ...
2025-07-29add-patch: add diff.context command line overridesLeon Michalak7-0/+22
This patch compliments the previous commit, where builtins that use add-patch infrastructure now respect diff.context and diff.interHunkContext file configurations. In particular, this patch helps users who don't want to set persistent context configurations or just want a way to override them on a one-time basis, by allowing the relevant builtins to accept corresponding command line options that override the file configurations. This mimics commands such as diff and log, which allow for both context file configuration and command line overrides. Signed-off-by: Leon Michalak <leonmichalak6@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-07-28builtin: unmark git-switch and git-restore as experimentalJustin Tobler2-4/+0
In 4e43b7ff (Declare both git-switch and git-restore experimental, 2019-04-25), the newly introduced git-switch(1) and git-restore(1) commands were marked as experimental. This was done to provide time to make breaking changes to the interface. It has now been over six years since these commands were implemented and there hasn't been much change. Consequently, users have grown to rely on how these commands work and it is no longer feasible to make any breaking changes. Let's remove the experimental label for git-switch(1) and git-restore(1). Signed-off-by: Justin Tobler <jltobler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-07-28for-each-ref: reword the documentation for '--start-after'Karthik Nayak1-1/+2
The documentation for '--start-after' states that the flag cannot be used with general pattern matching. This is a bit vague, since there is no clear understanding about what 'general' means here. Rewrite the sentence to be more specific. While here, fix a typo in the 'OPT_STRING'. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-07-28for-each-ref: fix documentation argument orderingKarthik Nayak1-5/+5
Improve the 'git-for-each-ref(1)' documentation with two corrections: 1. Add parentheses around `--exclude=<pattern>` to indicate this option can be repeated as a complete unit. 2. Move `--stdin | <pattern> ...` to the end, after all flags, since `<pattern>` is a positional argument that should appear last in the argument list. While here, change to using the synopsis block which will automatically format placeholders in italics and keywords in monospace. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>