Fatal: git was built without support for git-add--interactive (NO_PERL=1)

Question

When I do "git add -i" It pops this error:

fatal: git was built without support for git-add--interactive (NO_PERL=1)

I desperately need help!

Answer 1

With Git 2.25 (Q1 2020, five years later), Perl should no longer be a requirement for git add.
Here, "git add -i" is being rewritten in C.

Warning, since Git 2.37 (Q2 2022), the C rewrite is the default.
See the end of this answer.

See commit 8c15904, commit 3d965c7 (15 Nov 2019), and commit 1daaebc (13 Nov 2019) by Slavica Đukić (slavicaDj).
See commit 68db1cb, commit 76b7432, commit 6348bfb (15 Nov 2019), and commit f83dff6 (13 Nov 2019) by Johannes Schindelin (dscho).
See commit 5e82b9e, commit e4cb659 (13 Nov 2019) by Daniel Ferreira (theiostream).
^{(Merged by Junio C Hamano -- gitster -- in commit f7998d9, 05 Dec 2019)}

built-in add -i: implement the help command

^{Signed-off-by: Slavica Đukić
Signed-off-by: Johannes Schindelin}

This imitates the code to show the help text from the Perl script git-add--interactive.perl in the built-in version.

And:

built-in add -i: show unique prefixes of the commands

^{Original-patch-by: Slavica Đukić
Helped-by: SZEDER Gábor
Signed-off-by: Johannes Schindelin}

Just like in the Perl script git-add--interactive.perl, for each command a unique prefix is determined (if there exists any within the given parameters), and shown in the list, and accepted as a shortcut for the command.

To determine the unique prefixes, as well as to look up the command in question, we use a copy of the list and sort it.

While this might seem like overkill for a single command, it will make much more sense when all the commands are implemented, and when we reuse the same logic to present a list of files to edit, with convenient unique prefixes.

At the start of the development of this patch series, a dedicated data structure was introduced that imitated the Trie that the Perl version implements. However, this was deemed overkill, and we now simply sort the list before determining the length of the unique prefixes by looking at each item's neighbor. As a bonus, we now use the same sorted list to perform a binary search using the user-provided prefix as search key.

add-interactive.c explains:

A "prefix item list" is a list of items that are identified by a string, and a unique prefix (if any) is determined for each item.

At the beginning:

git add -i:Start to implement a built-in version of git add --interactive

^{Signed-off-by: Johannes Schindelin}

Unlike previous conversions to C, where we started with a built-in helper, we start this conversion by adding an interception in the run_add_interactive() function when the new opt-in add.interactive.useBuiltin config knob is turned on (or the corresponding environment variable GIT_TEST_ADD_I_USE_BUILTIN), and calling the new internal API function run_add_i() that is implemented directly in libgit.a.

The whole arc of the conversion can be found in the PRs #170-175 at github.com/gitgitgadget/git.

The "--helper approach" can unfortunately not be used here: on Windows we face the very specific problem that a system() call in Perl seems to close stdin in the parent process when the spawned process consumes even one character from stdin. Which prevents us from implementing the main loop in C and still trying to hand off to the Perl script.

The very real downside of the approach we have to take here is that the test suite won't pass with GIT_TEST_ADD_I_USE_BUILTIN=true until the conversion is complete (the --helper approach would have let it pass, even at each of the incremental conversion steps).

---

Note: You could see, with Git 2.25, the error message (reported in git-for-windows/git issue 2466):

BUG: pathspec.c:555: PATHSPEC_PREFER_CWD requires arguments

This should be fixed in Git 2.25.2 (March 2020).

See commit 849e43c, commit d660a30 (16 Jan 2020) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit f094074, 30 Jan 2020)}

built-in add -i: accept open-ended ranges again

^{Signed-off-by: Johannes Schindelin}

The interactive add command allows selecting multiple files for some of its sub-commands, via unique prefixes, indices or index ranges.

When re-implementing git add -i in C, we even added a code comment talking about ranges with a missing end index, such as 2-, but the code did not actually accept those, as pointed out in a comment of git-for-windows/git issue 2466 by qhill.

As an aside the rewrite of git add --interactive in C broke the ability to select files using an open range e.g. Patch update>> 2- to select all but the first file.
This is related to this issue as attempting this results in the same behaviour as in this issue (i.e. BUG in 2.24.1.windows.2 and immediate exit in 2.25.0.windows.1).

Let's fix this, and add a test case to verify that this stays fixed forever.

---

With Git 2.26 (Q1 2020), the effort to move "git-add--interactive" to C continues.

See commit c480eeb, commit cee6cb7, commit 52628f9, commit 6610e46, commit 90a6bb9, commit 36bae1d, commit d2a233c (21 Dec 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 9a5315e, 05 Feb 2020)}

built-in add -p: prepare for patch modes other than "stage"

^{Signed-off-by: Johannes Schindelin}

The Perl script backing git add -p is used not only for that command, but also for git stash -p, git reset -p and git checkout -p.

In preparation for teaching the C version of git add -p to support also the latter commands, let's abstract away what is "stage" specific into a dedicated data structure describing the differences between the patch modes.

Finally, please note that the Perl version tries to make sure that the diffs are only generated for the modified files. This is not actually necessary, as the calls to Git's diff machinery already perform that work, and perform it well. This makes it unnecessary to port the FILTER field of the %patch_modes struct, as well as the get_diff_reference() function.

---

Git 2.37 comes with git add -i in C by default.

If you have any issue, like msys2/MSYS2-packages issue 3066, try the workaround git config --global add.interactive.useBuiltin=false.

That particular issue should be resolved with Git 2.37.1 (Q3 2022): rewrite of "git add -i"^(man) in C that appeared in Git 2.25 did not correctly record a removed file to the index, which was fixed.

See commit 4788e8b (28 Jun 2022) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 0f0bc21, 02 Jul 2022)}

add --interactive: allow update to stage deleted files

^{Reported-by: Christoph Reiter
Signed-off-by: Johannes Schindelin}

The scripted version of git add -i^(man) used git update-index --add --remove``^(man), but the built-in version implemented only the --add part.

This fixes https://github.com/msys2/MSYS2-packages/issues/3066

The issue was, while usung an add interactive:

git add -i
fatal: unable to stat 'myfile': No such file or directory

---

Consequence of add.interactive.useBuiltin:

With Git 2.38 (Q3 2022), fix deadlocks between main Git process and subprocess spawned via the pipe_command() API, that can kill "git add -p"^(man) that was reimplemented in C recently.

See commit 716c1f6, commit c6d3cce, commit 14eab81, commit ec4f39b, commit 10f7433 (17 Aug 2022) by Jeff King (peff).
See commit 24b56ae (17 Aug 2022) by René Scharfe (rscharfe).
^{(Merged by Junio C Hamano -- gitster -- in commit a103ad6, 25 Aug 2022)}

pipe_command(): mark stdin descriptor as non-blocking

^{Signed-off-by: Jeff King}

Our pipe_command() helper lets you both write to and read from a child process on its stdin/stdout.
It's supposed to work without deadlocks because we use poll() to check when descriptors are ready for reading or writing.

But there's a bug: if both the data to be written and the data to be read back exceed the pipe buffer, we'll deadlock.

The issue is that the code assumes that if you have, say, a 2MB buffer to write and poll() tells you that the pipe descriptor is ready for writing, that calling:

write(cmd->in, buf, 2*1024*1024);

will do a partial write, filling the pipe buffer and then returning what it did write.
And that is what it would do on a socket, but not for a pipe.
When writing to a pipe, at least on Linux, it will block waiting for the child process to read() more.
And now we have a potential deadlock, because the child may be writing back to us, waiting for us to read() ourselves.

An easy way to trigger this is:

git -c add.interactive.useBuiltin=true \
    -c interactive.diffFilter=cat \
    checkout -p HEAD~200

The diff against HEAD~200 will be big, and the filter wants to write all of it back to us (obviously this is a dummy filter, but in the real world something like diff-highlight would similarly stream back a big output).

If you set add.interactive.useBuiltin to false, the problem goes away, because now we're not using pipe_command() anymore (instead, that part happens in perl).
But this isn't a bug in the interactive code at all.
It's the underlying pipe_command() code which is broken, and has been all along.

Answer 2

Thanks guys for your comments. I fixed it by removing git and installing it "apt-get install git."

The problem was that the Bitnami-LAMP VM came with a pre-built-git that, I guess, wasn't built with PERL. I checked my PERL version and is fine. Anyways, all is good.