Bug Report - Segmentation Fault on "git add --all"

Context: We currently have a git project with a root directory ("~/project") for pipelines and deployment of a Node app, and then a subdirectory ("~/project/project-app"). After realizing that we didn't need the node app in a subdirectory, we moved the full app into the root directory (using the mv command).

The Problem: Our node_modules folder is being tracked by git (173MB) and was moved into the root directory along with the other files. After moving the files, I ran "git add --all" in order to track the new files. Rather than the expected output of the (albeit very long) list of files, I was presented with a segmentation fault error.

[1]    90837 segmentation fault  git add --all

Attempting to run other git commands (commit, add) now responds with:

fatal: Unable to create '/Users/tillson/project/.git/index.lock': File exists.

Running "git status" shows that git successfully tracked that the original files within ~/project/project-app were deleted, but it did not pick up the "newly created" files from moving. Removing .git/index.lock (an empty file) allows for me to run "git commit" but no changes are recorded ("no changes added to commit"). Running "git add --all" again causes a seg fault and repeats the cycle.

I would assume that the cause of the seg fault was that node_modules held too much data for git to be able to handle in one go. I'm not sure if this is considered a (likely at this point known) bug or if it's just a caveat of using git. I am admittedly not an expert with git, so if there is anything useful (logs, config files, etc.) I can supply to help fix this, I'd be happy to.

Thanks, Tillson Galloway

On 20 July 2017 at 02:54, Tillson Galloway <tillson.galloway@gmail.com> wrote:

[...]

So you did "mv project-app/* ." and see something like

  Changes not staged for commit:
    (use "git add/rm <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)

      deleted:    ... lots of files ...

? That means Git has *realized* that the files are gone, but it's not *tracking* that fact (yet).

What if you restore the files and instead try "git mv project-app/* ."? It will move the files like "mv", but it will also do basically what you wanted to achieve with "git add --all". After that, you'll just have to "git commit".

You'll probably want to "rmdir project-app/" once it's empty. If you have some structure like project-app/project-app/ the move might fail (should be possible to work around).

This obviously doesn't address the problem you saw and on which I cannot comment, but I hope it helps you do what you actually wanted to do. :)

Martin