git/Documentation/git-add.adoc, branch main

Documentation: update add --force option + ignore=all config

2026-02-06T17:43:26Z

- git-add.adoc: Update the --force documentation for submodule behaviour to be added even the given configuration ignore=all. - gitmodules.adoc and config/submodule.adoc: The submodule config ignore=all now need --force in order to update the index. Signed-off-by: Claus Schneider(Eficode) Signed-off-by: Junio C Hamano

add-patch: fully document option P

2025-10-21T21:35:44Z

Show option P in the prompt and explain it properly on a dedicated line in online help and documentation. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

add-patch: let options k and K roll over like j and J

2025-10-06T17:51:42Z

Options j and J roll over at the bottom and go to the first undecided hunk and hunk 1, respectively. Let options k and K do the same when they reach the top of the hunk array, so let them go to the last undecided hunk and the last hunk, respectively, for consistency. Also use the same direction-neutral error messages. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

add-patch: let options y, n, j, and e roll over to next undecided

2025-10-06T17:51:42Z

The options y, n, and e mark the current hunk as decided. If there's another undecided hunk towards the bottom of the hunk array they go there. If there isn't, but there is another undecided hunk towards the top then they go to the very first hunk, no matter if it has already been decided on. The option j does basically the same move. Technically it is not allowed if there's no undecided hunk towards the bottom, but the variable "permitted" is never reset, so this permission is retained from the very first hunk. That may a bug, but this behavior is at least consistent with y, n, and e and arguably more useful than refusing to move. Improve the roll-over behavior of these four options by moving to the first undecided hunk instead of hunk 1, consistent with what they do when not rolling over. Also adjust the error message for j, as it will only be shown if there's no other undecided hunk in either direction. Reported-by: Windl, Ulrich Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

add-patch: document that option J rolls over

2025-10-06T17:51:42Z

The variable "permitted" is not reset after moving to a different hunk, so it only accumulates permission and doesn't necessarily reflect those of the current hunk. This may be a bug, but is actually useful with the option J, which can be used at the last hunk to roll over to the first hunk. Make this particular behavior official. Also adjust the error message, as it will only be shown if there's just a single hunk. Suggested-by: Junio C Hamano Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

add-patch: improve help for options j, J, k, and K

2025-10-06T17:51:42Z

The options j, J, k, and K don't affect the status of the current hunk. They just go to a different one. This is true whether the current hunk is undecided or not. Avoid misunderstanding by no longer mentioning the current hunk explicitly in their help texts. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

doc: rephrase the purpose of the staging area

2025-08-29T17:21:08Z

Git does not really "store the contents of the next commit" anywhere; rather, you the user use the index to prepare it. Signed-off-by: Julia Evans [jc; made the change relative to what is already in 'next'] Signed-off-by: Junio C Hamano

doc: git-add: simplify discussion of ignored files

2025-08-19T23:04:54Z

- 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 Signed-off-by: Junio C Hamano

doc: git-add: clarify intro & add an example

2025-08-19T23:04:52Z

- 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 Signed-off-by: Junio C Hamano

add-patch: add diff.context command line overrides

2025-07-29T15:52:45Z

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 Signed-off-by: Junio C Hamano