git add --interactive fails on subdir

[albfan]

Filtering on a path, to add interactively only files from subdir

> cd subdir
> git add -i .
Can't exec "git": Bad file number at C:\Program Files (x86)\Git/libexec/git-core\git-add--interactive line 180.
Died at C:\Program Files (x86)\Git/libexec/git-core\git-add--interactive line 180.

it is a perl script. I checked I'm using perl from msysgit installation.

>perl
"perl" no se reconoce como un comando interno o externo,
programa o archivo por lotes ejecutable.

>"\Program Files (x86)\Git\bin\perl.exe" --version

This is perl, v5.8.8 built for msys

My version of git is the latest 1.9.2

>git --version
git version 1.9.2.msysgit.0

[dscho]

Maybe running it after setting the environment variable GIT_TRACE to 1 sheds enough light into the issue?

[t-b]

Everything done in the msysgit/git repository.

$ GIT_TRACE=1 git add -i .
trace: built-in: git 'add' '-i' '.'
trace: run_command: 'add--interactive' '--' ''
trace: exec: 'git-add--interactive' '--' ''
trace: run_command: 'git-add--interactive' '--' ''
trace: built-in: git 'rev-parse' '--show-prefix'
trace: built-in: git 'config' '--get-colorbool' 'color.interactive' 'true'
trace: built-in: git 'config' '--get-color' 'color.interactive.prompt' 'bold blue'
trace: built-in: git 'config' '--get-color' 'color.interactive.header' 'bold'
trace: built-in: git 'config' '--get-color' 'color.interactive.help' 'red bold'
trace: built-in: git 'config' '--get' 'color.interactive.help'
trace: built-in: git 'config' '--get-color' 'color.interactive.error' 'red bold'
trace: built-in: git 'config' '--get-colorbool' 'color.diff' 'true'
trace: built-in: git 'config' '--get-color' 'color.diff.frag' 'cyan'
trace: built-in: git 'config' '--get-color' 'color.diff.plain' ''
trace: built-in: git 'config' '--get-color' 'color.diff.old' 'red'
trace: built-in: git 'config' '--get-color' 'color.diff.new' 'green'
trace: built-in: git 'config' '--get-color' '' 'reset'
trace: built-in: git 'config' '--get' 'diff.algorithm'
trace: built-in: git 'config' '--bool' '--get' 'interactive.singlekey'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'update-index' '--refresh'
trace: built-in: git 'ls-files' '--' ''
Can't exec "git": Bad file number at h:\msysgit/libexec/git-core\git-add--interactive line 180.
Died at h:\msysgit/libexec/git-core\git-add--interactive line 180.

Passing a relative and absolute directory works.

[t-b]

With the help of some debugging

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 32c2f9c..45b21a4 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -169,6 +169,7 @@ my %patch_modes = (
 my %patch_mode_flavour = %{$patch_modes{stage}};

 sub run_cmd_pipe {
+  print "args: @_\n";
        if ($^O eq 'MSWin32') {
                my @invalid = grep {m/[":*]/} @_;
                die "$^O does not support: @invalid\n" if @invalid;

I found out that git add -i . in git does not work but it works in contrib. So this looks like some commandline-too-long issue to me.

[albfan]

You are right. git status shows a long path from some changes. git add -i . on subdir with that paths fails, other subdirs with short paths works well, Is again bad windows file length design coming to bitting us?

[PhilipDavis]

I'm also seeing this issue with 1.9.4.msysgit.0

@albfan I don't think it's the Windows file name max length causing an issue. The command that fails appears to be calling "git diff-index --cached --numstat --summary HEAD -- {Every_Filename}" where {Every _Filename} is a lot of files.

I'm noticing the failure with ~40K of data. A quick Google search suggests the limit is 8K-1 (but might be out of date... anecdotally, I'd say the limit on Win7 might be more like 32K-1).

How feasible would it be to write all the filenames into a temp file or pass them via stdin rather than on the command line?

[t-b]

How feasible would it be to write all the filenames into a temp file or pass them via stdin rather than
on the command line?

If you know perl it should be quite easy.

What I'm actually asking myself is, why does upstream does not suffer from this bug? Okay the length limit on *nix is much longer (xargs --show-limits gives 2091634 on debian stable), but it is still no indefinite.

[dscho]

The common strategy in Git is to pass arguments via stdin if there is a danger of running into the command-line length limit.

[PhilipDavis]

@dscho That doesn't seem to work here... maybe I'm doing something wrong. For instance, the following command fails with fatal: bad revision 'filename':

git ls-files --full-name . | git diff-index --numstat --summary --raw --stdin

As far as I can tell, even when I hack the source to return the correct tracked list subset (as opposed to the entire repo tracked list), git diff-index is ignoring or failing when I pass the filenames on stdin...

[t-b]

@PhilipDavis
The help page of diff-index states

git diff-index [-m] [--cached] [] […]

So you have to pass a revision before the paths.

[rcdailey]

FYI: Still reproducible with Git 2.1 built from msysgit by hand

[kkheller]

For anyone still interested on this thread, I just posted "a patch for a patch" (a new update to @PhilipDavis's August 2014 work). You can see it here: #218 (comment)

Now "git add -p SOME_DIR" works for me 100% of the time again, no matter whether the SOME_DIR subfolder contains a dozen files or several hundred. (using today's patch)

I searched my error on google many times and never found this thread. In the future I will know to come straight to github and search the issues here. However, for the sake of others, I will post my error here in the hopes that it will help somebody else find their way to this issue tracker:

$ git add -p LargeFolder/
Can't exec "git": Bad file number at C:\msysgit\msysgit/libexec/git-core\git-add--interactive line 180.
Died at C:\msysgit\msysgit/libexec/git-core\git-add--interactive line 180.

(Other search terms for the SEO of this page: folder, subdirectory, directory, git add --patch pathspec, microsoft windows 7, win32, msys, bash, options)

(i was always searching with "git add -p". it seems that only @juliankrispel mentioned that exact invocation on msysgit/msysgit#203)

Notes about reproducing this:

git add -p SmallFolder/ # succeeds
git add -p FOLDER_WITH_HUGE_CONTENT/ # fails

In my case, here are the statistics for my FOLDER_WITH_HUGE_CONTENT:

find FOLDER_WITH_HUGE_CONTENT/ | wc -l produces a line count of 505.

find FOLDER_WITH_HUGE_CONTENT/ | wc -c produces a char count of 21734.

Anyway, i hope that others can take today's patch (#218 (comment)) and run it in their msysgit environment and experience the same relief from this issue as i have!

[dscho]

This will be fixed in Git for Windows 2.x via git-for-windows#305.