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

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

[Tillson Galloway]

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

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

[Martin Ågren]

On 20 July 2017 at 02:54, Tillson Galloway <tillson.galloway@gmail.com> wrote:
> 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).
>
[...]
>
> 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.

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