git/Documentation/git.adoc, branch jch

Merge branch 'os/doc-git-custom-commands'

2026-03-16T17:48:14Z

Doc update. * os/doc-git-custom-commands: doc: make it easier to find custom command information

Merge branch 'os/doc-custom-subcommand-on-path'

2026-03-12T17:56:03Z

The way end-users can add their own "git " subcommand by storing "git-" in a directory on their $PATH has not been documented clearly, which has been corrected. * os/doc-custom-subcommand-on-path: doc: add information regarding external commands

doc: make it easier to find custom command information

2026-03-07T22:04:23Z

Git supports creating additional commands through aliases, and through placement of executables with a "git-" prefix in the PATH. This information was not easy enough to find - users will look for this information around the command description, but the documentation exists in other locations. Update the "GIT COMMANDS" section to reference the relevant sections, making it easier for to find this information. Signed-off-by: Omri Sarig Signed-off-by: Junio C Hamano

doc: add information regarding external commands

2026-03-04T17:21:22Z

Git supports running external commands in the user's PATH as if they were built-in commands (see execv_dashed_external in git.c). This feature was not fully documented in Git's user-facing documentation. Add a short documentation to describe how PATH is used to find a custom subcommand. Signed-off-by: Omri Sarig Signed-off-by: Junio C Hamano

refs: add GIT_REFERENCE_BACKEND to specify reference backend

2026-02-25T17:40:00Z

Git allows setting a different object directory via 'GIT_OBJECT_DIRECTORY', but provides no equivalent for references. In the previous commit we extended the 'extensions.refStorage' config to also support an URI input for reference backend with location. Let's also add a new environment variable 'GIT_REFERENCE_BACKEND' that takes in the same input as the config variable. Having an environment variable allows us to modify the reference backend and location on the fly for individual Git commands. The environment variable also allows usage of alternate reference directories during 'git-clone(1)' and 'git-init(1)'. Add the config to the repository when created with the environment variable set. When initializing the repository with an alternate reference folder, create the required stubs in the repositories $GIT_DIR. The inverse, i.e. removal of the ref store doesn't clean up the stubs in the $GIT_DIR since that would render it unusable. Removal of ref store is only used when migrating between ref formats and cleanup of the $GIT_DIR doesn't make sense in such a situation. Helped-by: Jean-Noël Avila Signed-off-by: Karthik Nayak Signed-off-by: Junio C Hamano

Merge branch 'kh/you-still-use-whatchanged-fix'

2025-10-02T19:26:12Z

The "do you still use it?" message given by a command that is deeply deprecated and allow us to suggest alternatives has been updated. * kh/you-still-use-whatchanged-fix: BreakingChanges: remove claim about whatchanged reports whatchanged: remove not-even-shorter clause whatchanged: hint about git-log(1) and aliasing you-still-use-that??: help the user help themselves t0014: test shadowing of aliases for a sample of builtins git: allow alias-shadowing deprecated builtins git: move seen-alias bookkeeping into handle_alias(...) git: add `deprecated` category to --list-cmds Makefile: don’t add whatchanged after it has been removed

git: add `deprecated` category to --list-cmds

2025-09-17T20:47:22Z

With 145 builtin commands (according to `git --list-cmds=builtins`), users are probably not keeping on top of which ones (if any) are deprecated. Let’s expand the experimental `--list-cmds`[1] to allow users and programs to query for this information. We will also use this in an upcoming commit to implement `is_deprecated_command`. [1]: Using something which is experimental to query for deprecations is perhaps not the most ideal approach, but it is simple to implement and better than having to scan the documentation Acked-by: Patrick Steinhardt Helped-by: Patrick Steinhardt Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

progress: pay attention to (customized) delay time

2025-08-25T22:50:17Z

Using one of the start_delayed_*() functions, clients of the progress API can request that a progress meter is only shown after some time. To do that, the implementation intends to count down the number of seconds stored in struct progress by observing flag progress_update, which the timer interrupt handler sets when a second has elapsed. This works during the first second of the delay. But the code forgets to reset the flag to zero, so that subsequent calls of display_progress() think that another second has elapsed and decrease the count again until zero is reached. Due to the frequency of the calls, this happens without an observable delay in practice, so that the effective delay is always just one second. This bug has been with us since the inception of the feature. Despite having been touched on various occasions, such as 8aade107dd84 (progress: simplify "delayed" progress API), 9c5951cacf5c (progress: drop delay-threshold code), and 44a4693bfcec (progress: create GIT_PROGRESS_DELAY), the short delay went unnoticed. Copy the flag state into a local variable and reset the global flag right away so that we can detect the next clock tick correctly. Since we have not had any complaints that the delay of one second is too short nor that GIT_PROGRESS_DELAY is ignored, people seem to be comfortable with the status quo. Therefore, set the default to 1 to keep the current behavior. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'jc/doc-boolean-synonyms'

2025-02-21T18:35:53Z

Doc updates. * jc/doc-boolean-synonyms: doc: centrally document various ways tospell `true` and `false`

doc: use .adoc extension for AsciiDoc files

2025-01-21T20:56:06Z

We presently use the ".txt" extension for our AsciiDoc files. While not wrong, most editors do not associate this extension with AsciiDoc, meaning that contributors don't get automatic editor functionality that could be useful, such as syntax highlighting and prose linting. It is much more common to use the ".adoc" extension for AsciiDoc files, since this helps editors automatically detect files and also allows various forges to provide rich (HTML-like) rendering. Let's do that here, renaming all of the files and updating the includes where relevant. Adjust the various build scripts and makefiles to use the new extension as well. Note that this should not result in any user-visible changes to the documentation. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano