[PATCH] add: remove interactive mode

[PATCH] add: remove interactive mode

[shrimech]

Remove the --interactive (-i) option from git add and drop
its associated interactive-mode documentation.

The patch mode (--patch/-p) remains available for interactively
selecting hunks to stage.

Signed-off-by: shrimech <eddinen77@gmail.com>
---
 Documentation/git-add.adoc | 140 +++----------------------------------
 builtin/add.c              |  17 ++---
 2 files changed, 18 insertions(+), 139 deletions(-)

diff --git a/Documentation/git-add.adoc b/Documentation/git-add.adoc
index 941135dc63..89a6bbe309 100644
--- a/Documentation/git-add.adoc
+++ b/Documentation/git-add.adoc
@@ -8,7 +8,7 @@ git-add - Add file contents to the index
 SYNOPSIS
 --------
 [synopsis]
-git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
+git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--patch | -p]
 	[--edit | -e] [--[no-]all | -A | --[no-]ignore-removal | [--update | -u]] [--sparse]
 	[--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
 	[--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
@@ -87,23 +87,12 @@ in linkgit:gitglossary[7].
 	be removed from the working tree without warning. See
 	linkgit:git-sparse-checkout[1] for more details.
 
-`-i`::
-`--interactive`::
-	Add modified contents in the working tree interactively to
-	the index. Optional path arguments may be supplied to limit
-	operation to a subset of the working tree. See ``Interactive
-	mode'' for details.
-
 `-p`::
 `--patch`::
 	Interactively choose hunks of patch between the index and the
 	work tree and add them to the index. This gives the user a chance
 	to review the difference before adding modified contents to the
 	index.
-+
-This effectively runs `add --interactive`, but bypasses the
-initial command menu and directly jumps to the `patch` subcommand.
-See ``Interactive mode'' for details.
 
 include::diff-context-options.adoc[]
 
@@ -171,123 +160,16 @@ for `git add --no-all <pathspec>...`, i.e. ignored removed files.
 	them, do not abort the operation, but continue adding the
 	others. The command shall still exit with non-zero status.
 	The configuration variable `add.ignoreErrors` can be set to
-	true to make this the default behaviour.
-
-`--ignore-missing`::
-	This option can only be used together with `--dry-run`. By using
-	this option the user can check if any of the given files would
-	be ignored, no matter if they are already present in the work
-	tree or not.
-
-`--no-warn-embedded-repo`::
-	By default, `git add` will warn when adding an embedded
-	repository to the index without using `git submodule add` to
-	create an entry in `.gitmodules`. This option will suppress the
-	warning (e.g., if you are manually performing operations on
-	submodules).
-
-`--renormalize`::
-	Apply the "clean" process freshly to all tracked files to
-	forcibly add them again to the index.  This is useful after
-	changing `core.autocrlf` configuration or the `text` attribute
-	in order to correct files added with wrong _CRLF/LF_ line endings.
-	This option implies `-u`. Lone CR characters are untouched, thus
-	while a _CRLF_ cleans to _LF_, a _CRCRLF_ sequence is only partially
-	cleaned to _CRLF_.
-
-`--chmod=(+|-)x`::
-	Override the executable bit of the added files.  The executable
-	bit is only changed in the index, the files on disk are left
-	unchanged.
-
-`--pathspec-from-file=<file>`::
-	Pathspec is passed in _<file>_ instead of commandline args. If
-	_<file>_ is exactly `-` then standard input is used. Pathspec
-	elements are separated by _LF_ or _CR/LF_. Pathspec elements can be
-	quoted as explained for the configuration variable `core.quotePath`
-	(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
-	global `--literal-pathspecs`.
-
-`--pathspec-file-nul`::
-	Only meaningful with `--pathspec-from-file`. Pathspec elements are
-	separated with _NUL_ character and all other characters are taken
-	literally (including newlines and quotes).
-
-`--`::
-	This option can be used to separate command-line options from
-	the list of files, (useful when filenames might be mistaken
-	for command-line options).
-
-
-EXAMPLES
---------
-
-* Adds content from all ++*.txt++ files under `Documentation` directory
-  and its subdirectories:
-+
-------------
-$ git add Documentation/\*.txt
-------------
-+
-Note that the asterisk ++*++ is quoted from the shell in this
-example; this lets the command include the files from
-subdirectories of `Documentation/` directory.
-
-* Considers adding content from all ++git-*.sh++ scripts:
-+
-------------
-$ git add git-*.sh
-------------
-+
-Because this example lets the shell expand the asterisk (i.e. you are
-listing the files explicitly), it does not consider
-`subdir/git-foo.sh`.
-
-INTERACTIVE MODE
-----------------
-When the command enters the interactive mode, it shows the
-output of the 'status' subcommand, and then goes into its
-interactive command loop.
-
-The command loop shows the list of subcommands available, and
-gives a prompt "What now> ".  In general, when the prompt ends
-with a single '>', you can pick only one of the choices given
-and type return, like this:
-
-------------
-    *** Commands ***
-      1: status       2: update       3: revert       4: add untracked
-      5: patch        6: diff         7: quit         8: help
-    What now> 1
-------------
-
-You also could say `s` or `sta` or `status` above as long as the
-choice is unique.
-
-The main command loop has 6 subcommands (plus help and quit).
-
-status::
-
-   This shows the change between `HEAD` and index (i.e. what will be
-   committed if you say `git commit`), and between index and
-   working tree files (i.e. what you could stage further before
-   `git commit` using `git add`) for each path.  A sample output
-   looks like this:
-+
-------------
-              staged     unstaged path
-     1:       binary      nothing foo.png
-     2:     +403/-35        +1/-1 add-interactive.c
-------------
-+
-It shows that `foo.png` has differences from `HEAD` (but that is
-binary so line count cannot be shown) and there is no
-difference between indexed copy and the working tree
-version (if the working tree version were also different,
-'binary' would have been shown in place of 'nothing').  The
-other file, `add-interactive.c`, has 403 lines added
-and 35 lines deleted if you commit what is in the index, but
-working tree file has further modifications (one addition and
+	EDITING PATCHES
+	---------------
+
+	Invoking `git add -e` will open a patch in your editor; after the editor exits, the
+	result is applied to the index. You are free to make arbitrary changes
+	to the patch, but note that some changes may have confusing results, or
+	even result in a patch that cannot be applied.  If you want to abort the
+	operation entirely (i.e., stage nothing new in the index), simply delete
+	all lines of the patch. The list below describes some common things you
+	may see in a patch, and which editing operations make sense on them.
 one deletion).
 
 update::
diff --git a/builtin/add.c b/builtin/add.c
index 60ffbede2b..67d33b52a9 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -31,7 +31,7 @@ static const char * const builtin_add_usage[] = {
 	N_("git add [<options>] [--] <pathspec>..."),
 	NULL
 };
-static int patch_interactive, add_interactive, edit_interactive;
+static int patch_interactive, edit_interactive;
 static struct interactive_options interactive_opts = INTERACTIVE_OPTIONS_INIT;
 static int take_worktree_changes;
 static int add_renormalize;
@@ -255,7 +255,6 @@ static struct option builtin_add_options[] = {
 	OPT__DRY_RUN(&show_only, N_("dry run")),
 	OPT__VERBOSE(&verbose, N_("be verbose")),
 	OPT_GROUP(""),
-	OPT_BOOL('i', "interactive", &add_interactive, N_("interactive picking")),
 	OPT_BOOL('p', "patch", &patch_interactive, N_("select hunks interactively")),
 	OPT_BOOL(0, "auto-advance", &interactive_opts.auto_advance,
 		 N_("auto advance to the next file when selecting hunks interactively")),
@@ -408,21 +407,19 @@ int cmd_add(int argc,
 	if (interactive_opts.interhunkcontext < -1)
 		die(_("'%s' cannot be negative"), "--inter-hunk-context");
 
-	if (patch_interactive)
-		add_interactive = 1;
-	if (add_interactive) {
+	if (patch_interactive) {
 		if (show_only)
-			die(_("options '%s' and '%s' cannot be used together"), "--dry-run", "--interactive/--patch");
+			die(_("options '%s' and '%s' cannot be used together"), "--dry-run", "--patch");
 		if (pathspec_from_file)
-			die(_("options '%s' and '%s' cannot be used together"), "--pathspec-from-file", "--interactive/--patch");
+			die(_("options '%s' and '%s' cannot be used together"), "--pathspec-from-file", "--patch");
 		exit(interactive_add(repo, argv + 1, prefix, patch_interactive, &interactive_opts));
 	} else {
 		if (interactive_opts.context != -1)
-			die(_("the option '%s' requires '%s'"), "--unified", "--interactive/--patch");
+			die(_("the option '%s' requires '%s'"), "--unified", "--patch");
 		if (interactive_opts.interhunkcontext != -1)
-			die(_("the option '%s' requires '%s'"), "--inter-hunk-context", "--interactive/--patch");
+			die(_("the option '%s' requires '%s'"), "--inter-hunk-context", "--patch");
 		if (!interactive_opts.auto_advance)
-			die(_("the option '%s' requires '%s'"), "--no-auto-advance", "--interactive/--patch");
+			die(_("the option '%s' requires '%s'"), "--no-auto-advance", "--patch");
 	}
 
 	if (edit_interactive) {
-- 
2.53.0

Re: [PATCH] add: remove interactive mode

[Michael Montalbo]

On Tue, Aug 4, 2026 at 10:50 PM shrimech <eddinen77@gmail.com> wrote:
>
> Remove the --interactive (-i) option from git add and drop
> its associated interactive-mode documentation.
>
> The patch mode (--patch/-p) remains available for interactively
> selecting hunks to stage.
>
> Signed-off-by: shrimech <eddinen77@gmail.com>

I don't think this commit message is meaningful according to
Documentation/SubmittingPatches[1]:

    The body should provide a meaningful commit message, which:

    . explains the problem the change tries to solve, i.e. what is wrong
      with the current code without the change.

    . justifies the way the change solves the problem, i.e. why the
      result with the change is better.

    . alternate solutions considered but discarded, if any.

    . records the resolution of design or viability concerns raised by the
      community during the review, if any, ensuring the historical record
      explains why the chosen approach was accepted over alternatives.

[1] https://git-scm.com/docs/SubmittingPatches

Re: [PATCH] add: remove interactive mode

[Junio C Hamano]

Michael Montalbo <mmontalbo@gmail.com> writes:

> On Tue, Aug 4, 2026 at 10:50 PM shrimech <eddinen77@gmail.com> wrote:
>>
>> Remove the --interactive (-i) option from git add and drop
>> its associated interactive-mode documentation.
>>
>> The patch mode (--patch/-p) remains available for interactively
>> selecting hunks to stage.
>>
>> Signed-off-by: shrimech <eddinen77@gmail.com>
>
> I don't think this commit message is meaningful according to
> Documentation/SubmittingPatches[1]:
>
>     The body should provide a meaningful commit message, which:
>
>     . explains the problem the change tries to solve, i.e. what is wrong
>       with the current code without the change.
>
>     . justifies the way the change solves the problem, i.e. why the
>       result with the change is better.
>
>     . alternate solutions considered but discarded, if any.
>
>     . records the resolution of design or viability concerns raised by the
>       community during the review, if any, ensuring the historical record
>       explains why the chosen approach was accepted over alternatives.
>
> [1] https://git-scm.com/docs/SubmittingPatches

More importantly, a breaking change that will negatively affect
existing users' workflows needs to be accompanied by a much better
justification than a typical opt-in addition.

I could send a patch to remove 'git add' altogether, claiming that
"the diff feature remains available so 'git diff' will still work",
and yet that is not a sane justification for removing 'git add'.
Justifying the removal of '-i' based on the availability of '-p' is
just as bogus as that.

Of course, none of "I have not heard of this feature", "I have not
used this feature", "I no longer use this feature", and "I do not
like this feature" is good enough.  "I have not met anyone who uses
this feature" used to be viable twenty years ago, but not anymore.

Thanks.